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Abstract. 

This paper surveys the evolution of "high level" progranming languages 
during the first decade of computer programming activity. We discuss the 
contributions of Zuse ("Plankalkiil", 19^5), Goldstine/von Neumann ("Flow 
Diagrams", 19i+6), Curry ("Composition", 191^8), Mauchly et al. ("Short Code", 
1950), Burks ("Intermediate PL", 1950), Rutishauser (1951), Bohm (1951), 
Glennie ("AUTOCODE", 1952), Hopper et al. ("A-2", 1953), Laning/Zierler 
(1955), Backus et al. ("FORTRAN", 195i+-1957), Brooker ("Mark I Autocode", 
1951^), Kamynin/Liubimskii ("1^-2", 195^^), Ershov ("TTTT", 1955), Grems/Porter 
("BACAIC", 1955), Elsworth et al. ("Kompiler 2", 1955), Blum ("ADES", 1956), 
Perlis et al. ("IT", 1956), Katz et al. ("MATH-MATIC", 1956-1958), 
Hopper et al. ("FLOW-MATIC", 1956-1958), Bauer/ Samelson (1956-I95B). 
The principal features of each contribution are illustrated; and for 
purposes of comparison, a particular fixed algorithm has been encoded 
(as far as possible) in each of the languages. This research is based 
primarily on unpublished source materials, and the authors hope that they 
have been able to compile a fairly complete picture of the early 
developments in this area. 
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The Early Development of Programming Languages 

It is interesting and instructive to study the history of a subject 
not only because it helps us to understand how the important ideas were 
bom — and to see how the "human element" entered into each development — 
but also because it helps us to appreciate the amount of progress that 
has been made. This is especially striking in the case of programming 
languages, a subject which has long been undervalued by computer scientists. 
After learning a high-level language, a person often tends to think mostly 
of improvements he or she would like to see (since all languages can be 
improved), and it is very easy to underestimate the difficulty of creating 
that language in the first place. The real depth of this subject can 
only be properly perceived when we realize how long it took to develop 
the important concepts which we now regard as self evident. These ideas 
were by no means obvious a priori, and many years of work by brilliant 
and dedicated people were necessary before ovir current state of knowledge 
was reached. 

The goal of this paper is to give an adequate account of the early 
history of "high level" programming languages, covering roughly the first 
decade of their development. Our story will take us up to 1957, when the 
practical importance of algebraic compilers was first being demonstrated, 
and when computers were just beginning to be available in large numbers. 
We will see how people's fundamental conceptions of algorithms and of the 
programming process evolved during the years — not always in a forward 
direction -- culminating in languages such as FORTRAN I. The best languages 
we shall encounter are, of course, very primitive by today's standards, but 
they were good enough to touch off an explosive growth in language 
development; the ensuing decade of intense activity has been detailed in 
Jean Sammet's 785-page book [SA 69]. We shall be concerned with the more 
relaxed atmosphere of the "pre -Bab el" days, when people who worked with 
computers foresaw the need for important aids to programming that did not 
yet exist. In many cases these developments were so far anead of their 
time that they remained unpublished, and they are still largely unknown 
today. 



Altogether we shall be considering about 20 different languages, and 
it follows that we will have neither the space nor the time to characterize 
any one of them completely; besides, it would be rather boring to recite 
so many technical rules. The best way to grasp the spirit of a prograraming 
language is to read example programs, so we shall adopt the following 
strategy: A certain fixed algorithm — which we shall call the "TPK 
algorithm" for want of a better name-' — will be expressed as a program in 
each language we discuss. Informal explanations of this program should 
then suffice to capture the essence of the corresponding language, 
although the TPK algorithm will of co\irse not exhaust that language ' s 
capabilities; once we have understood the TPK program, we will be able 
to discuss the most important language featiires it does not reveal. 

Note that the same algorithm will be expressed in each language, 
in order to provide a simple means of comparison. A serious attempt 
has been made to write each program in the style originally used by the 
author of the corresponding language; and if comments appear next to the 
program text, they attempt to match the terminology used at that time 
by the original authors. Our treatment will therefore be something 
like "a recital of Chopsticks as it would have been played by Bach, 
Beethoven, Brahms, and Brubeck." The resulting programs are not truly 
authentic excerpts from the historic record, but they will serve as 
fairly close replicas; the interested reaxier can pursue each language 
further by consulting the bibliographic references to be given. 

The exemplary TPK algorithm which we shall be using so frequently 
can be written as follows in a dialect of Algol 60. 

1 TPK: 5£^£ ij2*^g^ i; ££Si y> ^^^ array a[0:10]; 

2 real procedure f(t); real t; value t; 
5 f := sqrt(abs(t)) +5 Xt t5; 

k for i := step 1 until 10 do read(a[i]): 

5 for i := 10 step -1 until do 

^ 5,S§i2, ^ •" f(a[i]); 

7 i£ y > lK)0 then write (i, "TOO LARGE") 

8 else write(i, y); 

9 end 

10 end. 

77 " ; 

— ' Cf . "Grimm's Law" in comparative linguistics, and/or the word "typical", 

and/or the names of the authors of this article. 
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(Actually Algol 60 is not one of the langusiges we shall be discussing, 
since it was a later development, but the reader ought to know enough 
about it to understand TPK. If not, here is a brief run-down on \diat 
the above program means: Line 1 says that i is an integer- valued 
variable, vftiile y takes on floating-point approximations to real 
values; and aQ, a^ ...,a.j^Q are also real valued. Lines 2 and 5 define 

the function f(t) = v|t| + 5t'^ , for use in the algorithm proper 
which starts on line h. Line k reads in the values a^, a, , . . .,a,_ , 
in this order; then line 5_ says to do lines 6, 7, 8, 9 (delimited by 
b^e^jn and end ) for i = 10,9^ ...,0 , in that order. The latter 
lines cause y to be set to f (a. ) , and then one of two messages is 
written out. The message is either the c^^rrent value of i followed 
by the words "TOO LARGE" , or the current values of i and y , 
according as y > i<-00 or not . ) 

Of course this algorithm is quite useless; but for our purposes 
it will be helpful to imagine ourselves vitally interested in the process. 
Let us pretend that the function f(t) ='\/|t| + 5t has a tremendous 
practical significance, and that it is extremely important to print out 
the function values f (a. ) in the opposite order from which the a. 
are received. This will put us in the right frame of mind to be reading 
the programs, (if a truly useful algorithm were being considered here, 
it would need to be much longer in order to illustrate as many different 
programming language features . ) 

Maoy of the programs we shall discuss will have italicized line 
numbers in the left-hand margin, as in the Algol code above- Such numbers 
are not really part of the programs, they appear only so that the 
accompanying text can refer easily to any particular line. 

It turns out that most of the early high-level languages were 
incapable of handling the TPK algorithm exactly as presented above; 
so we must make some modifications. In the first place, when a language 
deals only with integer variables, we shall assume that all inputs and 
outputs are integer valued, and that " sqrt(x) " denotes the largest 
integer not exceeding /x . Secondly, if the language does not provide 



for alphabetic output, the string "TOO LAEGE" will be replaced by the 
number 999 . Thirdly, some languages do not provide for input and 
output at all; in such a case, we shall assiane that the input values 
aQ, ap ...,a-,Q have somehow been supplied by an external process, and 
that our job is to compute 22 output values bQ,b,, . . .,bp, . Here 

'^Q}\} ' • ' >'^20 ^"^■'" ^^ *^® respective " i values" 10, 9,..., , and the 
alternate positions b, ,b , ...,b^^ will contain the corresponding f (a. ) 
values and/or 999 codes. Finally, if a language does not allow the 
programmer to define his own functions, the statement " y := f(a[i]) " 
will essentially be replaced by its expanded-out form 
"y := sqrt(abs(a[i])) +5 xa[i] t3 ". 



Before getting into real programming languages, let us try to set 
the scene by reAn.ewing the background very quickly. How were algorithms 
described prior to I9U5? 

The earliest known written algorithms come from ancient Mesopotamia, 

sequences of calculations on particiolar sets of data, not an abstract 
statement of the procedure; it is clear that strict procedures were 
being followed (since, for example, multiplications by 1 were explicitly 
performed), but they never seem to have been written down. Iterations 
like " for i := step 1 until 10 " were rare, but when present they 
would consist of a fully- expanded sequence of calcixlations . (See [M J2], 
for a survey of Babylonian algorithms.) 

By the time of Greek civilization, several nontrivial abstract 
algorithms had been studied rather thoroughly; for example, see [KN 69, 
p. 295] for a paraphrase of Euclid's presentation of "Euclid's algorithm". 
The description of algorithms was always informal, however, rendered 
in natural language. 

During the ensuing centuries, mathematicians never did invent a 
good notation for dynamic processes, although of course notations for 
(static) functional relations became highly developed. When a procedure 
involved nontrivial sequences of decisions, the available methods for 
precise description remained informal and rather cumbersome. 



Example programs written for early computing devices, such as those 
for Babbage's Calciilating Engine, were naturally presented in "machine 
language" rather than in a true programming language. Thus: (a) The 
three-address code for Babbage's machine was to consist of instructions 
such as " Vr xVq = V-Q ", where operation signs like " x" would appear 
on an Operation- card, and subscript nimibers like (U , , 10) would appear 
on a separate Variable-card. The most elaborate program developed by 
Babbage and Lady Lovelace for this machine was a routine for calculating 
Bernoulli nimibers; see [BA 6l, pp. 68, 286-297]. (b) In 191U, Leonardo 
Torres y Quevedo used natural language to describe the steps of a short 
program for his hypothetical automaton; and Helmut Schreyer gave an 
analogous description in 1959 for the machine he had helped Konrad Zuse 
to build [see RA 75, pp. 95-98^ I67]. (c) An example MARK I program 
given in l^h6 by Howard Aiken and Grace Hopper [see RA 73^ PP« 2l6-2l8] 
shows that its machine language was considerably more complicated. 

Although all of these early programs were in a machine language, 
it is interesting to note that Babbage had noticed already on July 9> I856 
that machines as well as people could produce programs as output: 

This day I had for the first time a general but very indistinct 
conception of the possibility of making an engine work out algebraic 
developments. I mean without any reference to the value of the 
letters. Hv notion is that as the cards (Jacquards) of the 
Calc. engine direct a series of operations and then recommence 
with the first so it might perhaps be possible to cause the same 
cards to punch others equivalent to any given number of repetitions. 
But there hole [sic] might perhaps be small pieces of formulae 
previously made by the first cards. [RA75, p. 3^9] 

To conclude this survey of prior developments, let us take a look at 
A. M. Turing's famous mathematical paper of 195^ [TU 36], where the 
concept of a universal computing machine was introduced for theoretical 
pvjrposes. Turing's machine language was more primitive, not having a 
built-in arithmetic capability, and he defined a complex program by 
giving vAiat amounts to macro-expansions or open subroutines. For example, 
here was his program for making the machine move to the leftmost " a" on 
its working tape: 
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[In order to carry out this operation, one sends the machine to state 
f(C, B, a) ; it will immediately begin to scan left (L) until first 

passing the symbol a . Then it moves right until either encountering 
the symbol a or two consecutive blanks; in the first case it enters 
into state C vAiile still scanning the a , and in the second case it 
enters state~ B after moving to the right of the second blank. Turing 
used the term ~ "m-configuration" for state.] 

Such "skeleton tables", as presented by Turing, represented the 
highest-level notations for precise algorithm description that were 
developed before our story begins -- except, perhaps, for Alonzo Church's 
"X. -notation" [GH 56] vrtiich represents an entirely different approach to 
calculation. Mathematicians would trad-itionaULy present the control 
mechanisms of algorithms informally, and the computations involved woxild 
be expressed by means of equations. There was no concept of assignment 
(i.e., of replacing the value of some variable by a new value); instead 
of writing " s • — s " one would write s , = -s , giving a new name to 
each quantity that would arise during a sequence of calculations. 

Zuse's "Plancalculus" . 

Near the end of World War II, Allied bombs destroyed nearly all of 
the sophisticated relay computers that Konrad Zuse had been biiilding in 
Germany since I956. Only his 2k machine could be rescued, in what Zuse 
describes as a fantastic ["abenteuerlich"] way; and he moved the 7h to 
a little shed in a small Alpine village called Hinterstein. 

my small group of twelve co-workers disbanded. But it was now a 
satisfactory time to pursue theoretical studies. The Th Computer 
which had. been rescued could barely be made to run, and no 
especially algorithmic language was really necessary to program 
it anyway. [Conditional commands had consciously been omitted; 
see [RA 73, p. I8I].] Thus the PK [ Flankalkiil ] arose purely as a 
piece of desk- work, without regard to whether or not machines 
suitable for PK' s programs would be available in the foreseeable 
future. [ZU 72, p. 6]. 



Zuse had previously come to grips witn the lack of formal notations 

for algorithms while working on his planned doctoral dissertation 

[ZU kh]. Here he had independently developed a three-address notation 

remarkably like that of Babbage; for exaarple, to ccmpute the roots 

2 
x^ and x^ of x+ax + b=0, given a = V, and b = V- , he 

prepared the following Rechenplan [p. 26]: 



V -2 
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realized that 
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notation was 






[so-called starre Plane ], and he concluded his previous manuscript with 

the following remark: 

Iftistarre Rechenplane constitute the true discipline of higher 
combinatorial computing; however, they cannot yet be treated in 
this place. [ZU kh, p. 3I] 

The completion of this work was the theoretical task Zuse set himself 
in 19^4-5, and he pursued it very energetically. The result was an amazingly 
ccmprehensive language which he called the Plankalklil [program calculus], 
an extension of Hilbert's AassagenkalMil [prepositional calculus] and 
Pradikatenkalkul [predicate calculus]. Before laying this project aside, 
Zuse had completed an extensive manuscript containing programs far more 
conrplex than anything ever written before. Among other things, there were 
algorithms for sorting; for testing the connectivity of a graph represented 
as a list of edges; for integer arithmetic (including square roots) in 
binary notation; and for floating-point arithmetic. He even developed 



algorithms to test -wtiether or not a given logical formula is syntactically 
■well-formed, and -j^ether or not such a formula contains redundant 
parentheses — assuming six levels of precedence between the operators. 
To top things off, he also included ij-9 pages of algorithms for playing 
chess . (Who would have believed that such pioneering developments 
could emerge from the solitary village of Hinterstein? His plans to 
include algorithms for matrix calculations, series expansions, etc., 
had to be dropped since the necessary contacts were lacking in that 
place; furthermore, his chess playing program treated "en passant 
captures" incorrectly, because he could find no chess boards or people 
to play chess with [ZU 72, pp. 52, 55] 1) 

Zuse's I9U5 manuscript unfortunately lay unpublished until 1972^ 
although brief excerpts appeared in I9I+8 and 1959 [ZU kS, ZU 59]; see also 
[BW72], where his work was brought to the attention of English-speaking 
readers for the first time. It is interesting to speculate about what 
would have happened if he had published everything at once; would many 
people have been able to imderstand such radical new ideas? 

The monograph [ZU Ji5] on Plankalltiil begins with the following 
statement of motivation: 

Aufgabe des Plankalkuls ist es, beliebige Rechenvorschriften rein 
formal darzustellen. [The mission of the Plancalculus is to 
provide a purely formal description of any computational procedure.] 

So, in particular, the Plankalkiil should be able to describe the TPK 
algorithm; and we had better turn now to this program, before we forget 
what TPK is all about. Zuse's notation may appear somewhat frightening 
at first, but we will soon see that it is really not difficult to understand. 
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Line 1 of this code is the declaration of a compound data type, and 
before we discuss the remainder of the program we should stress the richness 
of data structures provided by Zuse's language (even in its early fonn 
[ZU 1)4]). This is, in fact, one of the greatest strengths of the 
Plankallriil; none of the other languages we shall discuss had such a 
perceptive notion of data, yet Zuse's proposal was simple and elegant. 
He started with data of type SO , a single bit ["Ja-Nein-Wert"] whose 
value is either " -" or " +". From any given data types a , ...,a , 
a programmer could define the compound data type {a , ...,a ) , and 
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individual components of this compound type could be referred to by- 
applying the subscripts , ... , k-1 to any variable of that type. 
Arrays could also be defined by writing m x ^^ ^ meaning m identical 
components of type a ; and this idea could be repeated, in order to 
obtain arrays of any desired dimension. Furthermore m cotild be "D"^ 
meaning a list of variable length, and Zuse made good use of such list 
structtires in his algorithms dealing with graphs, algebraic formulas, and 
ches splay. 

Thus the Plankalkul included the important concept of hierarchically 
structured data, going all the way down to the bit level. Such advanced 
data structures did not enter again into programming languages until the 
late 1950' s, in IBM's Commercial Translator. The idea eventually 
appeared in many other languages, such as FACT, COBOL, PL/ 1, and 
extensions of ALGOL 60; cf. [CL 61] and [SA 69, p. 325]. 

Integer variables in the Plankallriil were represented by type A9 . 
Another special type was used for floating-binary numbers, namely 

AAl = (5 X SO , 7 X SO , 22 X SO) . 



The first three-bit component here was for signs and special markers — 
indicating, for example, whether the number was real or imaginary or zero; the 
second was for a seven-bit exponent in two's complement notation; and 
the final 22 bits represented the 25 -bit fraction part of a normalized niimber, 
with the redundant leading " 1" bit suppressed. Thus, for example, the 
floatino'-''^oint number ■+•^400*0 would have 3T'''^e°-**ed as 

(_+- , + , +__+) ^ 

and it also could be written 

(LO , LOOO , LOOLOOOOOOOOOOOOOOOOOO) . 

[The + 's and - 's notation has its bits niunbered 0,1, ... from left-to- 
right, -vAiile the L's and O's notation corresponds to the more familiar 
binary notation, putting most significant bits at the left.] There was a 
special representation for "infinite" and "very small" and "undefined" 
quantities; for example. 
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+ 00 = (LLO, LOOOO, 0) . 

Note that the above program uses + oo instead of 999 on line 15, since 
such a value seems an appropriate -way to render the concept "TOO LARGE" . 

Let us return now to the program itself. Line 1 introduces the data 
type A2 , namely an ordered pair whose first conponent is an integer 
(type A9 ) and whose second component is floating-point (type AAl ). 
This data tjrpe will be used later for the 11 outputs of the TPK algorithm. 
Lines 2 thru J^ define the function f (t) , and lines 8 thru 22 define the 
main TPK program. 

The hardest thing to get used to about Zuse's notation is the fact 

that each operation spans several lines; for example, lines 11 thru lU must 

be read as a unit. The second line of each group (labelled " V") is used 

to identify the subscripts for quajitities named on the top line; thus 

R , V , Z stands for the variables R , v^ , Z^, . Operations are done 
u u u 

primarily on output variables [" Result atwerte"] R^ , input variables 

["Variablen"] Vj^ , ajid intermediate variables ["Zwischenwerte"] Z, . 

The " K" line is used to denote components of a variable, so that, in 

our example, V means component i of the input variable V . 


i 

(A completely blank " K" line is normally omitted.) Complicated subscripts 

can be handled by making a zig-zag bar from the K-line up to the top line, 

as in line YJ_ of the above program where the notation indicates component 

10-i of Rq . The bottom line of each group is labeled A or S , and 

it is used to specify the type of each variable. Thus the " 2 " in line l8 

of our exaarple means that Rq is of type A2 ; the " Al " means that Z^ 

is floating-point (type AAl ); and the " 9" means that i is an integer. 

Thus each " A" in the left margin is implicitly attached to all types in 

its line. 

Zuse remarked [ZU i^5, p. 10] that the number of possible data types 

was so large, it would be impossible to indicate a variable's type simply 

by using typographical conventions as in classical mathematics; thus he 

realized the importance of apprehending the type of each variable at 

each point of a program, although this information is usually redundant. 

This is probably one of the main reasons he introduced the peculiar 

multi-line format. Incidentally, a somewhat similar multi-line notation 
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has been used in recent years to describe musical notes [SM 73] j it is 
interesting to speculate if this notation will evolve in the same way 
that programming languages have. 

We are now ready to penetrate further into the meaning of the above 
code. Each plan begins with a specification part ["Randauszug"]^ stating 
the types of all inputs and outputs. Thus, lines 2 thru h mean that PI 
is a procedure that takes an input V„ of type AAL (floating point) and 
produces R„ of the same type. Lines 8 thru 10 say that P2 maps V^ of 
type 11 X AAl (namely, a vector of 1 floating-point numbers, the array a. 
of our TPK algorithm) into a result R„ of type 11 x A2 (namely, a vector 
of 11 ordered pairs as described earlier). 

The double arrow => , which Zuse called the Ergibt-Zeichen (yields-sign), 
was introduced for the assignment operation; thus the meaning of lines 5. 
thru 2_ should be clear. As we have remarked, mathematicians had never 
used such an operator before; in fact, the systematic use of assignments 
constitutes a distinct break between computer- science thinking and 
mathematical thinking. Zuse consciously introduced a new symbol for the 

new operation, remarking [ZU k^, p. 15] that Z + 1 => Z was analogous to 

3 3 
to the more traditional equation Z +1 = Z . (incidentally, the 

3.i 5.i+l 

pub]j.shers of [ZU U3] used the sign >= instead of => , but Zuse never 

actually wrote >= himself. ) Note that the variable recei\'lng a new value 

appears on the right, while most present-day languages have it on the left. 

We shall see that there was a gradual "leftist" trend as languages 

developed. 

It remains to imderstand lines 11 thru 22 of the example. The notation 

" W2(n) " represents an iteration, for i = n-1 down to , inclusive; 

hence W2(ll) stands for the second for loop in the TPK algorithm. 

(The index of such an iteration was always denoted by i , or i.O ; if 

another iteration were nested inside, its index would be called i.l , 

etc.) The notation Rl(x) on line 11 stands for the result Rq of 



applying procedure PI to input x . Lines 15 thru l8 of the program mean 

" if Zq > il-00 then RQ[10-i] := (l , +<») "; note Zuse's new notation -^ 

for conditionals. Lines 1^ thru 22 are similar, the bar over " Zq > ^00 " 

indicating the negation of that relation. There was no equivalent of 

" else " in the Plankalkiil, nor were there go to statements. Zuse did, 



ll; 



however, have the notation " Fin " with superscripts, to indicate a 
jiomp out of a given number of iteration levels and/or to the beginning 
of a new iteration cycle [cf. ZU 72, p. 28; ZU 45, p. 52]; this idea 
has recently been revived in the BLISS language [WR 71] . 

The reader should now be able to understand the above code completely. 
In the text accompanying his programs in Plankalkul notation, Zuee 
made it a point to state also the mathematical relations between the 
variables which appeared. He called such a relation an impliciter Ansatz ; 
we would now call it an "invariant". This was yet another fundamental 
idea about programming; and, like Zuse's data structures, it disappeared 
from programming languages during the 1950' s, waiting to be enthusiastically 
received when the time was ripe [HO 7I] . 

Zuse had visions of using the Plankalkiil some day as the basis of a 
programming language that could be translated by machine (cf . [zU 72 
pp. 3, 18,33, 3^]); but in I9U5, he was considering first things first 
— namely, he needed to decide what concepts should be embodied in a 
notation for programming. We can summarize his accomplishments by 

it lacked the "syntactic sugar" for expressing programs in a readable 
and easily writable format. 

Zuse says he made modest attempts in later years to have the 
Plankalkiil implemented within his own company, "but this project 
necessarily foundered because the expense of implementing and designing 
compilers outstripped the resources of my small firm." He also mentions 
his disappointment that more of the ideas of the Plankalkiil were not 
incorporated into Algol 58, since some of Algol's original designers 
knew of his work. [ZU 72, p. 7] Such an outcome was probably inevitable, 
because the Plankalkiil was far ahead of its time from the standpoint of 
available hardware and software development. Most of the other languages 
we shall discuss started at the other end, by asking what was possible 
to implement rather than what was possible to write; and it naturally 
took many years for these two approaches to come together and to achieve 
a suitable synthesis. 
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Flow Diagrams. 

On the other side of the Atlantic, Herman H. Goldstine and John 
von Neumann were wrestling with the same sort of problem that Zuse had 
faced: How shoiild algorithms be represented in a precise way, at a 
higher level than the machine's language? Their answer, which was due 
in large measure to Goldstine' s analysis of the problem together with 
suggestions by von Neiimann, Adele Goldstine, and Arthur W. Burks [GO 72, 
pp. 266-268], was quite different from the Plankalkul: they proposed a 
pictorial representation involving boxes joined by arrows, and they called 
it a "flow diagram". During 19^+6 and 19^7 they prepared an extensive 
and carefully worked out treatise on programming based on the idea of 
flow diagrams [GV kj], and it is interesting to compare this work to 
that of Zuse. There are striking differences, such as an emphasis on 
numerical calculation rather than on data structures; and there are also 
striking parallels, such as the use of the term "Plan" in the titles of 
both documents. Although neither work was published in contemporary 
Joiimals, perhaps the most significant difference was that the treatise 
of Goldstine and von Neumann was beautifully "Varityped" and distributed 
in quantity to the vast majority of people involved with computers at 
that time. This fact, coupled with the high quality of presentation and 
von Neumann's prestige, meant that their report had an enormous impact, 
forming the foundation for computer programming techniques all over the 
world. The term "flow diagram" became shortened to "flow chart" and 
eventually it even became "flowchart" — a word which has entered our 
language as both noun and verb. 

We all know what flowcharts are; but comparatively few people have 
seen an authentic original flow diagram. In fact, it is very instructive 
to go back to the original style of Goldstine and von Neumann, since 
their inaugural flow diagrams represent a transition point between the 
mathematical "equality" notation and the computer-science "assignment" 
operation. Here is how the TPK algorithm wovild probably have looked, 
if Goldstine and Von Neumann had been asked to deal with it in 19^7: 
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Several things need to "be explained about this original notation, 
and probably the most important consideration is the fact that the boxes 
containing " 10 - i " and " i-1 -* i " were not intended to specify any 
ccmputation. This amounts to a significantly different viewpoint than 
we are now accustomed to, and the reader will find it worth\diile to 
ponder this conceptual difference until he or she understands it. The 
box " i-1 -» i " represents merely a change in notation, as the flow 
of control passes that point, rather than an action to be performed by 

the computer. For example, box VII has done the courputatioi necessary 

-39 / 
to place 2 (i-1) into storage position C.l ; so after we pass the 

box " i-1 -► i " and go thru the subsequent junction point to box II, 

location C.l now contains 2 "^^i . The external notation has changed 

but location C.l has not I This distinction between external and internal 

notations occurs throu^out, the external notation being problem-oriented 

■while the actual contents of memory are machine-oriented. The numbers 

attached to each arrow in the diagram indicate so-called "constancy 

intei^als", -where all memory locations have constant contents and all 

bound variables of the external notation have constant meaning. 

A "storage table" is attached by a dashed line to the constancy intervals, 

to show the relevant relations between external and internal values at 

that point. Thus, for example, we note that the box " 10 - i " does 

not specify any computation, but it provides the appropriate transition 

from constancy interval 1.5 to constancy interval 2 . (Cf. [GV h"], 

§§ 7.6, 7.7].) 

There were four kinds of boxes in a flow diagram: (a) Operation 

boxes, marked with a Roman numeral; this is where the computer program 

was supposed to make appropriate transitions in storage, (b) Alternative 

boxes, also marked with a Roman numeral, and having two exits marked + 

and - ; this is where the computer control was to branch, depending on 

the sign of the named quantity, (c) Substitution boxes, marked with a 

# and using the " -• " symbol; this is where the external notation for 

a bound variable changed, as explained above, (d) Assertion boxes, also 

marked with a # ; this is where important relations between external 

notations and the current state of the control were specified. The 

example shows three assertion boxes, one which says " i = -1 ", and two 
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which assert that the outputs u. and v. (in a problem-oriented 
notation) now have certain veilues. Like substitution boxes, assertion 
boxes did not indicate any action by the computer, they merely stated 
relationships which helped to prove the validity of the program and 
>diich might help the programmer to write code for the operation 
boxes. 

The next most prominent feature about original flow-diagrams is 
the fact that a programmer was required to be conscious of the scaling 
(i.e., the binary point location) of all niimbers in the computer memory. 
A computer word was 1+0 bits long and its contents was to be regarded as a binary 
fraction x in the range -1 < x < 1 . Thus, for example, the above 
flowchart assumes that 2 a. is initially present in storage position 

J 

A.j , rather than the value a. itself; and the output^ b. are 

J J 

similarly scaled. 

The final mystery -which needs to be revealed is the meaning of 

notations such as (a+i)^ , (^)o ' ^*'^* ^^ general, " x " was used 

when X was an integer machine address; and it represented the number 

--19 . „-^9 _ , , . .... ... ... 

d X + £1 X , xitunexy a. Dxnary wura wita x appear ±iig twice, xa Dit 

positions 9 to 20 and 29 to ko (counting from the left). Such a 

nimiber could be used in their machine to modify the addresses of 20-bit 

instructions that appeared in either half of a ItO-bit word. 

Once a flow diagram such as this had been drawn up, the remaining 

task was to prepare so-called "static coding" for boxes marked with 

Roman numerals. In this task a programmer would use his problem- solving 

ability, together with his knowledge of machine language and the 

information from storage tables and assertion boxes, to make the required 

transitions. For example, in box VI one should use the facts that u. = i. 



that 
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storage D contains 2 v. , that storage C.l contains 2~^-^i , 
and that storage C.3 contains (b+20-2i) [a word corresponding to 
the location of variable B.20-2i ] to carry out the specified assignments. 
The job of box VII is slightly trickier: One of the tasks, for example, 
is to store (b + 22 -2i)„ in location C.3 ; the programmer was supposed 
to resolve this by adding 2- (2" +2~^-^) to the previous contents of C.l 
In general, the job of static coding required a fairly high level of 
artificial intelligence, and it was far beyond the state of the art in 
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in those days to get a computer to do such a thing. As with the 
Plankalkul, the notation needed to be simplified if it was to be 
s\iitable for machine implementation. 

Let us make one final note about flow diagrams in their original 
form: Goldstine and von Neumann did not suggest any notation for 
subroutine calls, hence the function f(t) in the TPK algorithm has 
been written in-line. In [(N k'J, §12] there is a flow diagram for 
the algorithm that a loading routine must follow in order to relocate 
subroutines from a library, but there is no example of a flow diagram 
for a driver program that calls a subroutine. An appropriate extension 
of flow diagrams to subroutine calls coiild surely be made, but it would 
have made our example less "authentic". 

A Logician ' s Approach . 

Let us now turn to the proposals made by Haskell B. Curry, who was 
working at the Naval Ordnance Laboratory in Silver Spring, Maryland; 
his activity was partly contemporaneous with that of Goldstine and 
von Neumann, since the last portion of [GV k'j] was not distributed until 
19U8. 

Curry wrote two lengthy memoranda [CU 48, CU 50] which have never 
been published; the only appearance of his work in the open literature 
has been the brief and somewhat cryptic summary in [CU 50']. He had 
prepared a rather complex program for ENIAC in 19k6, and this experience 
led him to suggest a notation for program construction that is more 
compact than flowcharts. 

His aims, which correspond to important aspects of what we now call 
"structured programming", were quite laudable: 

The first step in planning the program is to aneilyze the computation 
into certain main parts, called here divisions, such that the 
program can be synthesized from them. Those main parts must be 
such that they, or at any rate some of them, are independent 
computations in their own right, or are modifications of such 
computations. [CU 50,^ 3^] 
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But in practice his proposal was not especially successful, because 
the way he factored a problem was not very natural; his components 
tended to have several entrances and several exits, and perhaps his 
mathematical abilities tempted him too strongly to pursue the complexities 
of fitting such pieces together. As a result, the notation he developed 
was somewhat eccentric; and the work was left unfinished. Here is how 
he might have represented the TPK algorithm: 

F(t) = [4\t\ + 5t^:A} 

I = {10:i} -. {t = L(a+i)} - F(t) - {A:y} 

- II - lt^(0,i) - O^&I^ 

II = {x = L(b + 20 -2i)} - {i:x} - III 

- [w = L(b + 21 -2i)} - {y:w} 

III = [y > too] - {999:y}&0^ 

The following explanations should suffice to make the example clear, 
although they do not reveal the full generality of his language; 

{E:x} means "compute the value of expression E and store it in 

location x '* . 
A denotes the accumulator of the machine. 
{x = L(E)} means "compute the value of expression E and substitute 

it into all appearances of ' x ' in the following instruction 

groups" . 
X -» Y means "substitute instruction group Y for the first exit 

of instruction group X ". 
I. denotes the j-th entrance of this routine, namely the beginning 

of its J-th instruction group. 
0. denotes the j-th exit of this routine (he used the words "input" 

and "output" for entrance and exit), 
{x > y} - O-i^&Og means "if x > y , go to 0, , otherwise to ". 

It (m, i) -♦ 0- &0 means "decrease i by 1 , then if i > m go 
to Op , otherwise to 0, ". 

Actually the main feature of interest in Curry's early work is not 
this prograimning language, but rather the algorithms he discussed for 
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converting parts of it into machine language. He gave a recixrsive 
description of a procedure to convert fairly general arithmetic ejqpressions 
into code for a one-address computer, thereby being the first person to 
describe the code-generation phase of a compiler. (Syntactic analysis 
was not specified; he gave recxirsive reduction rules analogous to well- 
knovm constructions in mathematical logic, assuming that any formula 
could be parsed properly.) His motivation for doing this was stated in 
[CU 50']: 

Now von Neumann ajid Goldstine have pointed out that, as programs 
are made up at present, we sho\ild not use the technique of program 
composition [i.e., subroutines] to make the simpler sorts of programs 
— these would be programmed directly — but only to avoid 
repetitions in programs of some complexity. Nevertheless, there 
are three reasons for pushing clear back to formation of the 
simplest programs from the basic programs [i.e., machine langiiage 
instructions], viz.: (l) Experience in logic and in mathematics 
shows that an insight into principles is often best obtained by a 
consideration of cases too simple for practical use — e.g., one 
gets an insight into the nature of a group by considering the 
permutations of three letters, etc. ... (2) It is quite possible 
that the technique of program composition can completely replace 
the elaborate methods of Goldstine axid von Neumann; while this may 
not work out, the possibility is at least worth considering. 
(5 ) The technique of program composition can be mechanized; if 
it should prove desirable to set up programs, or at any rate certain 
kinds of them, by machinery, presumably this may be done by 
analyzing them clear down to the basic programs. 

The program he would have constructed for F(t) , if t-^ were replaced by 

t't't , is 

[|tl:A} - [v^:A} - [A:w3 - [t:R] -* [tK:A} - {A:Ej - [tR:A} 
- {A:R} - {5R:A] -* {A+w:A} . 

Here w is a temporary storage location, and R is a register used in 
m\altiplication . 
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An Algebraic Interpreter. 

The three languages we have seen so far were never implemented; they 
served purely as conceptual aids during the programming process. Such 
conceptual aids were obviously iiirportant, but they still left the 
programmer with a lot of mechanical things to do, and there were many 
chances for errors to creep in. 

The first "hi^-level" programming language actually to be implemented 
was the Short Code, originally suggested by John W. Mauchly in 19i^9. 
William F. Schmitt coded it for the BIMC at that time. Late in I950, 
Schmitt recoded Short Code for the IMIVAC, with the assistance of 
Albert B. Tonik, and J. Robert Logan revised the program in January of 1952. 
Details of the system have never been published, and the earliest 
extant programmer's manual [RE 55] seems to have been written originally 
in 1952. 

The absence of data about the early Short Code indicates that it 
was not an instant success, in spite of its eventual historic significance. 

number of scientific users of UNIVAC equipment in those days; in fact, 
the most surprising thing is that an algebraic language such as this was 
not developed first at the mathematically-oriented centers of computer 
activity. Perhaps the reason is that mathematicians were so conscious 
of efficiency considerations, they could not imagine wasting any extra 
computer time for something a programmer could do by himself. Mauchly 
had greater foresight in this regard; and J. E. Logan put it this way: 

By means of the Short Code, any mathematical equations may 
be evaluated by the mere expedient of writing them down. There 
is a simple symbological transformation of the equations into 
code as explained by the accompanying write-up. The need for 
special programming has been eliminated. 

In our comparisons of computer time with respect to time 
consumed by manual methods, we have found so far a speed ratio 
of at least fifty to one. We expect better results from future 
operations. 
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... It is expected that future use of the Short Code will 
demonstrate its power as a tool in mathematical research and 
as a checking device for some large-scale problems. [RR 55] 

We cannot be certain how UNIVAC Short Code looked in 1950; but 
it probably was closely approximated by the 1952 version, when TPK 
co\ild have been coded in the following way. 

Memory eqiiivalents: i = WO , t = TO , y = YO . 

Eleven inputs go respectively into words UO , T9 , T8 , . . . , TO . 

Constants: ZO = 000000000000 

Zl = 010000000051 [1.0 in floating-decimal form] 

Z2 = 010000000052 [10. O] 

Z5 = Ol<0000000055 [1^00.0] 
7h = AAATOOALAEGE 

25=050000000051 [5.0] 

Equation number recall information [labels]: 

= line 01 , 1 = line 06 , 2 = line 07 

Short Code: 

Equations Coded representation 

00 i = 10 00 00 00 WO 03 Z2 

01 0: y = (/ abs t) + 5 cube t TO 02 07 Z5 11 TO 

02 00 YO 05 09 20 06 
22. y UOO if<to 1 00 00 00 YO K kl 
Oij^ i print, 'TOO LARGE' print -and-retum 00 00 7h 59 WO 58 

05 if=to 2 00 00 00 ZO ZO 72 

06 1: i print, y print- and-retum 00 00 YO 59 WO 58 
22. 2: TO UO shift 00 00 00 TO UO 99 
28 i = i-1 00 WO 03 WO 01 Zl 
22 i if<to 00 00 00 ZO WO ko 
10 stop 00 00 00 00 zz o8 
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Each IMIVAC word consisted of twelve 6-bit bytes, and the Short 
Code equations were "symbologically" transliterated into groups of six 
2-byte packets using the following equivalents (among others): 

01 - 06 abs value In (n+2)nd power 59 print and return carriage 

02 ( 07 + 2n (n+2)nd root yn if= to n 

05 = 08 pause kn if<to n 99 cyclic shift of memory 
0^ / 09 ) 58 print and tab Sn, Tn, ...,Zn quantities 

Thus, " i = 10 " would actually be coded as the word " 00 00 00 WO 03 72 " 
as shown; packets of 00 ' s could be used at the left to fill a word. 
Multiplication was indicated simply by Juxtaposition (see line 01). 

The system was an algebraic interpreter, namely an interpretive 
routine which continuously scanned the coded representation and performed 
the appropriate operations. The interpreter processed each word from 
right to left, so that it would see the "=" sign last. This fact needed 
to be -understood by the programmer, who had to break long equations up 
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print instructions on lines OU and 06, -^Aiere the codes rim from right 
to left. 

This explanation should suffice to explain the TPK program above, 
except for the "shift" on line 02;. Short Code had no provision for 
subscripted variables, but it did have a 99 order which perfonned a 
cyclic shift in a specified block of memory. For example, line 0^ of 
the above program means " temp = TO, TO = Tl, . . ., T9 = UO, UO = temp "; 
and fort\mately this facility is all that the TPK algorithm needs. 

The following press release from Remington Rand appeared in Journal 
of the ACM, 1955, page 291: 

Automatic programming, tried and tested since 1950, eliminates 
communication with the computer in special code or language. ... 
The Short-Order Code is in effect an engineering "electronic 
dictionary" ... an interpretive routine designed for the solution 
of one-shot mathematical and engineering problems. 
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(Several other automatic prograratnlng systems, including "B-zero" — which 

we shall discuss later — were also announced at that time.) This is one 

of the few places \^ere Short Code has been mentioned in the open 

literatiore; Grace Hopper referred to it "briefly in [HO 52, p. 2^5] 

(calling it "short-order code"), [HO 55> V- 1^2] ("short-code"), 

[HO 58, p. 165] ("Short Code"). In [HM 53, p. 1252] it is stated that 

the "short code" system was "only a first approximation to the complete 

plan as originally conceived." This is probably true, but several 

discrepancies between [HM 55] and [RR 55] indicate that the authors 

of [HM 55] were not fully familiar with UNIVAC Short Code as it actually 

existed. 

The Intermediate PL of Burks. 

Independent efforts to simplify the job of coding were being made 
at this time by Arthur W. Burks and his colleagues at the Iftiiversity of 
Michigan. The overall goal of their activities was to investigate the 
process of going from the vague "Ordinary Business English" description 
of a data-processing problem to the "Internal Program Language" description 
of a machine-language program for that problem; and, in particular, to 
break this process up into a sequence of smaller steps. 

This has two principal advantages. First, smaller steps can 
more easily be mechanized than larger ones. Second, different 
kinds of work can be allocated to different stages of the 
process and to different specialists. [BU 51, p. 12] 

In 1950, Burks sketched a so-called "Intennediate Programming Language" 
which was to be the step one notch above the Internal Program Language. 
Instead of spelling out conrplete rules for this Intermediate Programming 
Language, he took portions of two machine programs previously published 
in [BU 50] and showed how they could be expressed at a higher level of 
abstraction. From these two exanrples it is possible to make a reasonable 
guess at how he might have written the TPK algorithm at that time: 
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Repeat cycle until i negative 



Stop execution 
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Comments at the right of this program attenrpt to indicate Burks 's 
style of writing comments at that time; and they succeed in making the 
program almost completely self-explanatory. Note that the assignment 
operation is well established by now; and Burks used it also in the 
somewhat unusual form " i -♦ i+1 " shown in the comment to instruction ^k 
[BU 50, p. 1^1]. 

The prime symbol which appears within instruction 50 meant that the 
computer was to save this intermediate result, as it was a common 
subexpression that could be used later without recomputation. Burks 
mentioned that several of the ideas embodied in this language were due 
to Janet Wahr, Don Warren, and Jesse Wright. 

Methods of assigning addresses and of expanding abbreviated 
commands into sequences of commands can be worked out in advance. 
Hence the computer could be instructed to do this work. ... It 
should be emphasized, however, that even if it were not efficient 
to use a computer to make the translation, the Intermediate PL 
would nevertheless be useful to the human programmer in planning 
and constructing programs. [BU ^1, p. 13 ] 

At the other end of the spectrum, nearer to Ordinary Business 
Language, B\irks and his colleagues later proposed an abstract form of 
description which may be of independent interest, even though it does 
not relate to the rest of our story. The following example suffices 
to give the flavor of their "first Abstraction Leinguage", proposed in 
195U: 
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FORM XI: CUSTOMER'S STATEMENT 
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On the first line, c denotes the customer's name and address; and d 
is " 1 inst ", the first of the current month. The symbol L-^. (x-., . ..,x ) 
was used to denote a list of all n- tuples (x^,...,x ) of category i , 
in order by the first component x^ ; and the meaning of the second line 
is "a listing, in order of date d , of all invoices and all remittances 
for the past month". Here [k, s,u] was an invoice, characterized by 
its number k , its dollar amo'unt s , and its discount u ; [a, r] was 
a remittance of r dollars, identified by number a ; and " 1 ult " means 
the first of the previous month. The bottom gives the customer's old 
balance from the previous statement, and the new balance on the right, 
"The notation is so designed as to leave unprejudiced the method of the 
statement's preparation." [BC 5^] Such notations have not won over the 
business coramunity, however, perhaps for the reasons explained by 
Grace Hopper in [HO 58, p. I98]: 

I used to be a mathematics professor. At that time I found there 
were a certain number of students ■who could not learn mathematics. 
I then was charged with the job of making it easy for businessmen 
to use our computers. I found it was not a question of lidi ether 
they could learn mathematics or not, but -sAiether they would. . . • 
They said, "Throw those symbols out — I do not know what they mean, 
I have not time to learn symbols," I suggest a reply to those 
who woTild like data processing people to use mathematical symbols 
that they make them first attempt to teach those symbols to 
vice-presidents or a colonel or admiral. I assiore you that I 
tried it. 

Rutishauser's contribution. 

Now let us shift our attention once again to Europe, -where the first 
published report on methods for machine code generation was about to 
appear. Heinz Rutishauser was working with the 7h computer -vAiich, by 
then, had been rebuilt and moved to the Swiss Federal Institute of 
Technology (E.T.H. ) in Zurich; and plans were afoot to build a brand new 
machine there. The background of Rutishauser's contribution can best be 
explained by quoting from a letter he wrote some years later: 
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I am proud that you are taking the trouble to dig into my 1952 
paper. On the other hand it makes me sad, because it reminds me 
of the premature death of an activity that I had started hopefully 
in I9U9, but could not continue after I951 because I had to do 
other work — to run practically singlehanded a fortunately slow 
computer as mathematical analyst, programmer, operator and even 
trouble shooter (but not as an engineer). This activity forced 
me also to develop new numerical methods, simply because the ones 
then known did not work in larger problems. Afterwards when I 
wo\jld have had more time, I did not come back to automatic 
programming but found more taste in nimierical analysis. Only much 
later I was invited — more for historical reasons, as a living 
fossil so to speak, than for actual capacity — to join the ALGOL 
ventiore. The I952 paper simply reflects the stage i^ere I had to 
give up automatic programming, and I was even glad that I was able 
to put out that interim report (although I knew that it was final). 
[RU 63] 

Rutishauser's comprehensive treatise [EU 52] described a hypothetical 
computer and a simple algebraic language, together with complete 
flowcharts for two compilers for that language. One compiler expanded 
all loops out completely, -vdiile the other produced compact code using 
index registers. His source language was somewhat restrictive, since 
there was only one nonsequential control structure (the for statement); 
but that control structure was in itself an important contribution to 
the later development of programming languages. Here is how he might 
have written the TPK algorithm: 

1 Flir i = 10(-1)0 

2 a^ =^ t 

3 (Sqrt Abs t) + (5 xt xt xt) ^ y 
h Max(Sgn(y-li00), 0) :^ h 

5 Z Oi =^ ^20-2i 

6 (h X 999 ) + ( (1-h ) x y ) :^ b23__2i 
2_ Ende Index i 

8 Schluss 
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Since no "if ... then" construction — much less go to — was present 
in his language, the computation of 



y , if y < I+OO , 
999 , if y > 1+00 , 



has been done here in terms of the Max and Sgn functions he did have, 
plus appropriate arithmetic; see lines k and 6. (The flmction Sgn(x) 
is if X = , or +1 if x > , or - 1 if x < . ) Another 
problem was that he gave no easy mechanism for converting between 
indices and other variables; indices (i.e., subscripts) were completely 
tied to Fur - Ende loops. The above program therefore invokes a 
trick to get i into the main formula on line k; " Z 0. " is intended 
to use the Z instruction which transfered an indexed address to the 
accumulator in Rutishauser' s machine [RU 52, p. 10], and it is possible 
to write this in such a way that his compiler would produce the correct 
code. It is not clear whether or not he would have approved of this 
trick; if not, we could have introduced another variable, maintaining 
its value equal to i . But since he later wrote a paper entitled 
"Interference with an ALGOL procedure," there is some reason to believe 
he would have enjoyed the trick very much. 

As with Short Code, the algebraic source code symbols had to be 
transliterated before the program was amenable to computer input, and 
the programmer had to allocate storage locations for the variables and 
constants. Here is how our TPK program would have been converted to a 
sequence of (floating-point) numbers on punched paper tape, using the 
memory assignments a. = 100 +i , b. = 200 + i , = JOO , 1 = 501 , 
5 = 502 , ifOO = 505 , 999 = 504 , y = 505 , h = 506 , t = 507 : 
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Fiir i = 10 (-1) 

1 lO-"^ , 50 , 10 , -1 , , Q , 

begin stmt a sub i =^ t 

2 010000 , 100 , .001 , 200000 , 3O7 , Q, , 

begin stmt ( t Abs d-ummy Sqrt 

3 010000 , 010000 , 307 , 110000 , , 350800 , 

dummy ) + ( 5 X t x 
, 2000000 , 020000 , 010000 , 502 , O6OOOO , 3O7 , O6OOOO , 

■t X t ) ^7 
507 , 060000 , 307 , 200000 , 200000 ,305, Q , 

begin stmt ( ( y _ h,QQ ) sgn 

h 010000 , 010000 , 010000 , 305 , 030000 , 303 , 200000 , 100000 , 

dummy ) Max :^ h 

, 200000 , 080000 , 300 , 2000000 , 3O6 , Q , 

begin stmt Z sub i ^ b sub -2i 

5 010000 , , 250000 , , .001 , 200000 , 220 , -.002 , Q , 

begin stmt ( h x 999 ) + ( 

6 0100000 , 010000 , 306 , 060000 , 30U , 200000 , 020000 , 010000 , 

( 1 - h ) X y ) ^ 

010000 , 301 , 030000 , 506 , 200000 , 060000 , 305 , 200000 , 200000 , 





Dp, SUD -cfl 






221 , -.002 , 


Q , 




Ende 




1 


Schluss 




8 


Q , Q . 





52 



Here Q represents a special flag that was distinguishable from 
all numbers. The transliteration is straightforward, except that unary 
operators such as " Absx" have to be converted to binary operators 
" X Abs " . An extra left parenthesis is inserted before each formula, 
to match the ^= (which has the same code as right parenthesis). 
Subscripted variables whose address is a + L c,.i,. are specified by 



3J 



a+ Ti c.i . 
writing the base address a followed by a sequence of values c .10 
this scheme allows multiple subscripts to be treated in a simple way. 
The operator codes were chosen to make life easy for the compiler; 
for example, 020000 was the machine operation "add" as well as the 
input code for + , so the compiler could treat almost all operations 
alike. The codes for left and right parentheses were the same as the 
machine operations to load and store the accumulator, respectively. 

Since his compilation algorithm is published and reasonably simple, 
we can exhibit exactly the object code that would be generated from the 
above source input. The output is fairly long, but we shall consider 
it in its entirety in view of its importance from the standpoint of 
compiler history. Each word in Rutishauser' s machine held two instructions, 
and there were 12 decimal digits per instniction word. 



Machine instruction 

230010 200050 

250001 120000 

200051 250000 

200052 220009 
259001 200081 

000000 250100 

200099 010050 

020099 210001 

011000 200507 

010507 110000 

220009 550800 

000000 000000 

200999 010502 



Symbolic form 

10 - Op , Op - i , 
1 - Op , -Op - Op , 
Op -» i' , -* Op 
Op - i"'' , ^1 -* IE 
1+IRq -► Op , Op -. L-|_ 
No-op , loc a -♦ Op 
Op -* T , i - Op 
OpfT - Op , Op - IR^ 
a. -• Op , Op -* t 
t - Op , |0p| - Op 
*+l - IRq , go to Sqrt 
no-op, no-op 
Op - P^ , 5 - Op 
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Machine Instruction Symbolic form 

060307 060307 Opxt-Op, Opxt-Op 

060307 200998 Opxt-Op, Qp-Pg 

010999 020998 Pj_ - Op , Op+Pg - Op 

200305 010305 Op -» y , y -* Op 

030303 200999 Op-li-00 - Op , Op - P^ 

010999 100000 P^ - Op , Sgn Op -» Op 

200998 010998 Op ^ Pg , Pg -* Qp 

080300 200306 Max(Op,0) - Op , Op - h , 

230000 200099 - Op , Op - T 

010050 020099 i - Op , Op+-T - Op 

210001 230220 Op - IR^ , loc b^Q - Op 

200099 230002 Op -» T , 2 - Op 

120000 060050 -Op -Op, Opxi-C>P 

020099 210002 Op^-T -» Op , Op - lEg 

010000 251000 (0) -* Op , IR^ - Op 

202000 250221 Op - ^20-2i ' """^^ ^21 "* ^ 

200099 250002 Op - T , 2 - Op 

120000 060050 -Op - Op , Op X i -» Qp 

020099 210001 Op+T - Op , Op - IRj_ 

010501 050506 1 - Op , Op-h - Op 

200999 010306 Op - P^ , h -» Op 
060301^ 200998 Op x999 -* Op , Op - Pg 
010999 060505 P-j_-QP7 Opxy-op 
200997 010998 Op -. p , Pg -* Qp 

020997 201000 Op^"P:^ - Op , Op -» D21-2i 

010081 210009 L^. "* ^ ' Op - IRq 

010050 220008 i -. Op , ■'HI -* IRg 

030052 388003 Orp-i" - Op , to (IR8+5) if Op = 

010050 020051 i - Op , Opfi'' - Qp 

200050 559000 Op - i , to (IRq) 

000000 999999 no-op , stop 

999999 stop 
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(Several bugs on pp. 39-14-0 of [RU 52] needed to be corrected in order 
to produce this code, but Rutishauser's original intent was reasonably 
clear. The most common error made by a person who first tries to write 
a compiler is to confuse compilation time with object-code time, and 
Rutishauser gets the honor of being first to make this errori ) 

The above code has the interesting property that it is completely 
relocatable — even if we move all instructions up or down by one -half 
a word. Careful study of the output shows that index registers were 
treated rather awkwardly; but after all, this was 1951^ and many 
compilers even nowadays produce far more disgraceful code than this. 

Rutishauser published slight extensions of his soiirce language 
notation in [RU 55] and [RU 55']. 



Bbhm' s Compiler. 

An Italian graduate student, Corrado Bohm, developed a ccmpiler at 
the same time and in the same place as Rutishauser, so it is natiiral to 
assume — as many people have — that they worked together. But in fact, 
their methods had essentially nothing in common. Bohm (who was a student 
of Eduard Stiefel) developed a language, a machine, and a translation 
method of his own, during the latter part of 1950, knowing only of 
[GV 1+7] and [ZU U8]; he learned of Rutishauser's similar interests only 
after he had submitted his doctoral dissertation in 1951^ and he amended 
the dissertation at that time in order to clarify the differences between 
their approaches. 
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Bohm's dissertation [BO 52] was especially remarkable because he 
not only described a complete compiler, he also defined that compiler 
in its own language'. And the language was interesting in itself, 
because every statement (including input statements, output statements, 
and control statements) was a special case of an assignment statement. 
Here is how TPK looks in Bohm's language: 

A. Set i = (plus the 
base address 100 for 
the input array a ) . 

B. Let a new input a. be 
given. Increase i by unity, 
and proceed to C if i > 10 , 
otherwise repeat B. [(1 Q (i-110))»C]+[ (l-(i-llO)) -B] - jt 

C. Set i = 10 . 



D. Call X the number a. , 
and prepare to calculate 
its square root r (using 
subroutine R ), returning 
to E . 

E. Calculate f(a^) and it' -. E 
attribute it to y . r+-5'ii- ii-U -» y 
If y > 1^00 , continue [ (l n (y-^+OO) ) •F]+ [ (l- (y-UOO) ) -G] ^ it 
at F, otherwise at G. 

F. Output the actual value it' -« F 
of i , then the value i-100 - ? 
999 ("too large"). 999 - ? 
Proceed to H. H -• it 



It' 


— • 


A 


100 


— ♦ 


i 


B 


- 


It 


It' 


-♦ 


B 


9 


— • 


n 


i+1 


—► 


i 


•B] 


— ♦ 


It 


It' 


— » 


c 


110 


- 


i 


It' 


— ♦ 


D 


ii 


— ♦ 


X 


E 


— * 


X 


R 


_ 


It 
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G. Output the actual 
values of i and y 



It' 


- G 


i-100 


_ 9 


y 


_♦ 7 


H 


-« Tt 



H. Decrease i by unity, «' -» H 

and return to D if i-1 -• i 

i>0. Otherwise stop. [ (l-(lOOii)) •D]+[ (l H (lOO-i) ) -O] 



It 



Here comments in an approximation to Bbhm's style appear on the left, 
■while the program itself is on the right. As remarked earlier, every- 
thing in Bohm's language appears as an assignment. The statement 
" B -• It " means " go to B ", i.e., set the program coimter n to the 
value of variable B . The statement " it' -» B " meajis "this is label B"; 
a loading routine preprocesses the object code, using this type of 
statement to set the initial value of variable B rather than to store 
an instruction in memory. The symbol " ? " stands for the external 
world, hence the statement " ? -> x " meeins "input a value and assign 
it to x"; the statement " x -♦ ? " means "output the ciorrent value of x". 
An arrow " i " is used to indicate indirect addressing (restricted to 
one level); thus, " ? -» ii " in part B means "read one input into the 
location viiose value is i ", namely into a. . 

Bohm' s machine operated only on nonnegative integers of Ik decimal 
digits. As a consequence, his operation x-y was the logician's 
subtraction operator, 

{x-y , if X > y ; 
, if X < y . 

He also used the notation xfly for min(x, y) . Thus it can be verified 
that 
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l-(i-J) = 



if i > J ; 
if i < j . 



Because of these identities, the coniplicated fonnula at the end of part B 
is equivalent to a conditional branch, 

C - n , if i > 110 ; 
B - It , if i < 110 . 

It is easy to read Bohm' s program with these notational conventions 
in mind. Note that part C doesn't end with " D -» ir ", although it could 
have; similarly we could have deleted " B -• n " after part A. (Bohm 
omitted a redundant go-to statement only once, out of six chances he 
had in [BO 52].) 

Part D shows how subroutines are readily handled in his language, 
eilthough he did not explicitly mention them. The integer square root 
subroutine can be programmed as follows, given the input x and the 
exit location X : 



R. Set r = and t = 2 
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S. If rt-t < X , go to T , 
otherwise go to U . 

T. Decrease x by r+t , 

divide r by 2 , increase 
r by t , and go to V . 

U. Divide r by 2 . 



It' - R 

- r 

703687^1^17766^1 - t 

S -» It 

It' - S 

T+t - X -t U 

[(l-u).T] + [(inu).U] -^ It 

It' -» T 

x-r-t -• X 

r:2+t -» r 

V - It 

It' -* U 

r:2 -• r 

V -> It 



58 



V. Divide t by 4 . If t = , rt' -. U 

exit, otherwise return to S. t:i4^ -» t 

[(in).x]+[(int).s] - n 

(This algorithm is equivalent to the classical pencil- and-paper method 
for square roots, adapted to binary notation. It was given in hardware- 
oriented form as example P9.18 by Zuse in [ZU h5, pp. I^J-ISQ], To prove 
its validity, one can verify that the following invariant relations hold 
vAien we reach step S: 

t is a power of k ; 
r is a multiple of kt ; 
r^/Ut + X = initial value of x ; 
< X < 2r+lit . 

At the conclusion of the algorithm these conditions hold with t = l/U ; 
so r is the integer square root and x is the remainder.) 

Bohm's one-pass compiler was capable of generating instructions 
rapidly, as the input was being read from paper tape. Unlike Rutishauser, 
Bohm recognized operator precedence in his language; for example, r:2+t 
was interpreted as (r:2)+t , the division operator " : " taking 
precedence over addition. However, Bohm did not allow parentheses to be 
mixed with precedence relations: If an expression began with a left 
parenthesis, the expression had to be fully parenthesized even -vAien 
associative operators were present; on the other hand if an expression 
did not begin with a left parenthesis, precedence was considered but no 
parentheses were allowed within it. The complete program for his 
compiler consisted of lllj- assignments, broken dovm as follows: 

(i) 59 statements to handle formtilas with parentheses 

(ii) 51 statements to handle formulas with operator precedence 

(iii) k statements to decide between (i) and (ii). 

There was also a loading routine, described by 16 assignment statements; 
so the compiler amounted to only I30 statements in all, including 53 
statements which were merely labels («• -*...) . This brevity is 
especially surprising when we realize that a good deal of the program 
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was devoted solely to checking the input for correct syntax; this check 
was not complete, however. [It appears to be necessary to add one more 
statement in order to fix a hug in his program, caused by overlaying 
information -vghen a left parenthesis follows an operator symbol; but even 

with this "patch" the conrpiler is quite elegant.] 

2 
Eutishauser's parsing technique often required order n steps to 

process a formula of length n . His idea, which we have seen illustrated 

above, was to find the leftmost pair of parentheses which have the highest 

level, so that they enclose a parenthesis-free formula a , and to compile 

the code for " a -♦ P " ; then the subf ormula " (a) " was simply replaced 

by " P ", q was increased by 1 , and the process was iterated until 

no parentheses remained. Bbhm's parsing technique, on the other hand, 

was of order n , generating instructions in what amounts to a linked 

binary tree while the formula was being read in; to some extent, his 

algorithm anticipated modem list-processing techniques, which were first 

made explicit by Newell, Shaw, and Simon about 195 6 (cf. [KN 68, p. h37]) . 

Here is a brief indication of how Bohm' s algorithm would have translated 

the statement ((a: (b-c))+((d ne)-f )) — g , assuming that the bug referred 

to above had been removed: 
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At this point the contents of the tree would be punched out^ in reverse 
pre order: 

dne - © 

©-f -® 

b-c -©' 

a:© -@ 

©+© -® 

and the following symbol " g " would evoke the final instruction " fl) - g " 
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Bohm' s compiler assumed' that the source code input woiild be trans- 
literated into numeric form, but in an Italian patent filed in 1952 he 
proposed that it should actually be punched on tape using a typewriter 
with the following keyboard [BO 52 ', Fig. 9]: 

00000®®©©© 
®®®®®©©©®00 
®®®©©®0® ©© 
®® ®® © 0® ©© 
( > ) 



Constants in the source program were to be assigned a variable name and 
input separately. 

Of all the authors we shall consider, Bohm was the only one -vAao gave 
an argument that his language was universal , i.e., capable of computing 
any conrputable function. 



Mean-vAiile, in England. 

Our story so far has introduced us to many firsts, such as the first 
algebraic interpreter, the first algorithms for parsing and code generation, 
the first ccmpiler in its own language. Now we come to the first real 
compiler, in the sense that it was really implemented and used; it really 
took algebraic statements and translated them into machine language. 

nru ^ » -u ^ -^ — -c* x-u J _ j— n t. atj_i_ t\ f~%-t !« -»-c» t\ »- tt^t-^j-^ .3 

j.iic uuiisuiifj xiciu ux uiixc) U.C V cj-upuicxi o waa jij.j.t;ii. Hj, vj-lciuixc ux x ux o ncu-is i/cchj., 

the Royal Armaments Research Establishment. We may justly say "unsung" 
because it is very difficult to deduce from the published literature that 
Glennie introduced this system. When Christopher Strachey referred favorably 
to it in [ST 52, pp. hS-kj], he did not mention Glennie 's name, and it was 
inappropriate for Glennie to single out his own contributions when he co-authored 
an article with J. M. Bennett at the time [BG 53, pp. 112-113]. In fact, 
there are apparently only two published references to Glennie' s authorship 
of this early compiler; one of these was a somewhat cryptic remark inserted 
by an anonymous referee into a review of Bohm's paper [TA 56] while the 
other appeared in a comparatively inaccessible publication [MG 53]. 
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Glennie called his system AUTOCODE; and it may well have helped to inspire 
many other "Autocode" routines, of increasing sophistication, developed 
dxiring the late 1950's. Strachey said that AUTOCODE was beginning to 
come into use in September, 1952. The Manchester Mark I machine language 
was particularly abstruse -- see [WO 51] for an introduction to its 
complexities, including the intricacies of Teleprinter code (used for 
base-52 arithmetic, backwards) -- and its opaqueness may have been ■why 
this particular computer witnessed the world's first compiler. Glennie 
stated his motivations this way, at the beginning of a lecture he 
delivered at Cambridge Uii varsity in February, 1953 : 

The difficulty of programming has become the main difficulty 
in the use of machines. Aiken has expressed the opinion that the 
solution of this difficulty may be sought by building a coding 
machine, and indeed he has constructed one. However it has been 
remarked that there is no need to build a special machine for 
coding, since the computer itself, being general purpose, should 
be used. ... To make it easy, one must make coding comprehensible . 
This may be done only by improving the notation of programming. 
Present notations have many disadvantages: all are incomprehensible 
to the novice, they are all different (one for each machine) and 
they are never easy to read. It is quite difficult to decipher 
coded programmes even with notes, and even if you yourself made 
the programme several months ago. 

AssTiming that the difficulties may be overcome, it is obvious 
that the best notation for programmes is the usual mathematical 
notation, because it is already known. ... 

Using a familiar notation for programming has very great 
advantages, in the elimnation of errors in programmes, and the 
simplicity it brings. [GL 52] 

His reference to Aiken should be clarified here, especially because 
Glennie stated several years later [GL 65] that "I got the concept from 
a reported idea of Professor Aiken of Harvard, who proposed that a 
machine be built to make code for the Harvard relay machines." Aiken's 
coding machine for the Harvard Mark III was cited also by Bohm 
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[BO 52, p. 176]; it is described in [HA 52, pp. 36-38, 229-263, illustrated 
on pp. 20, 37, 230]. By pushing appropriate buttons on the console of 
this machine, one or more appropriate machine codes would be p-unched 
on tape for the equivalent of three-address instructions such as 
" -b5 X I ci I - ai " or " l//x9 -. rO " ; there was a column of keys for 
selecting the first operand's sign, its letter name, and its (single) 
subscript digit, then another column of keys for selecting the function 
name, etc. (incidentally, Heinz Rutishauser is listed as one of the 
fifty-six authors of the Harvard report [HA 52]; his visit to America 
in 1950 is one of the reasons he and Bohm did not get together.) 

Our TPK algorithm can be expressed in Glennie's AUTOCODE as follows: 
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Although this language was much simpler than the Mark I machine code, 
it was still very machine-oriented, as we shall see. (Rutishauser and 
Bohm had had a considerable advantage over Glennie in that they had 
designed their own machine codel) Lines 1-10 of this program represent 
a subroutine for calculating f(t) ; " CLOSE WRITE 1 " on line 10 says 
that the preceding lines constitute subroutine number 1. The remaining 
^iii-_is j,j.=.^v-. oiic ^iiSiii j^i ogij. aiiij wnixij t: DxAiii c oil line 3^ says that 
the preceding lines constitute subroutine number 2, and that execution 
steirts with number 2 . 

Let's begin at the beginning of this program and try to give a 
play-by-play account of ;.Aiat it means. Line 1 is a storage assignment 
for variables c , t , x , y , and z , in terms of absolute machine 
locations represented in the beloved Teleprinter code. Line 2 assigns 
the value 5 to c ; like all early compiler-writers, Glennie shied 
away from including constants in formulas. Actually his language has 
been extended here: he had only the statement "FRACTIONS" for producing 
constants between - ^ and ^ , assuming that a certain radix point 
convention was being used on the Manchester machine. Since scaling 
operations were so complicated on that computer, it would be inappropriate 
for our purposes to let such considerations mess up or distort the 
TPK algorithm; thus the INTEGERS statement (which is quite in keeping 
with the spirit of his language) has been introduced to simplify oui' 
exposition. 
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Upon entry to subroutine 1, the subroutine's argument was in the 
machine's lower accumulator; line 5 assigns it to variable t . Line h_ 
means " go to label Z if t is positive " ; line 5. puts -t in the 
accumulator; and line 6 defines label Z' . Thus the net effect of lines 
h thru 6 is to put jt| into the lower accumulator. Line ']_ applies 
subroutine 6 (integer square root) to this value, and stores it in z . 
On line 8^ we compute the product of t by itself; this fills both 
upper and lower accumulators, and the upper half (assumed zero) is 
stored in y , the lower half in x . Line 9 is similar, now x 
contains t^ . Finally line 10 completes the calculation of f (t) 
by leaving z+5x in the accumulator. The "CLOSE" operator causes the 
compiler to forget the meaning of label Z , but the machine addresses 
of variables c , x , y , and z remain in force. 

Line 11 introduces new storage assignments, and in particular it 
reassigns the addresses of c and x . New constant values are defined 
on line 12. Lines IJ thru l8 constitute the input loop, enclosed by 
LOOP lOn ... REPEAT n ; here n denotes one of the index registers 
(the famous Manchester B-lines), the letters k,l,n,o,q,r 
being reserved for this purpose. Loops in Glennie's language were 
always done for decreasing values of the index, up to and including ; 
and in our case the loop was performed for n = 20, l8, l6, ...,2,0 . 
These values are twice what might be expected, because the Mark I 
addresses were for half-words. Lines l4 thru l6 set index q equal 
to 20-n ; this needs to be done in stages (first moving from n to 
a normal variable, then doing the arithmetic, and finally moving the 
result to the index variable). The compiler recognized conversions 
between index variables and normal variables by insisting that all 
other algebraic statements begin with a + or - sign. Line 12_ says 
to store the result of subroutine 5 (an integer input subroutine) into 
variable a 

Lines 20 thru 51 comprise the output loop. Again n has the value 2i , 
so the true value of i has been maintained in parallel with n (see 
lines 12 and 30) . Line 21 applies subroutine 1 (namely our subroutine 
for calciilating f (t) ) to a and stores the result in y . Line 22 
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branches to label Z if UOO > y ; line 25 is an unconditional Jump 
to label X . Line 25 outputs the integer i , using subroutine 3, and 
subroutine k in line 2h is assumed to be similar except that a carriage- 
return and line-feed are also output. Thus the output is correctly- 
performed by lines 22 thru 29. 

The operations " MTRY A CONTROL A " on line 52 define an infinite 
loop " A: go to A " ; this was the so-called dynamic stop used to 
terminate a computation in those good old days. 

Our analysis of the sample program is now complete. Glennie's 
language was an important step forward, but of course it still remained 
very close to the machine itself. And it was intended for the use of 
experienced programmers. As he said at the beginning of the user's 
manual [GL 52'], "The left hand side of the equation represents the 
passage of information to the accxraiulator through the adder, subtracter, 
or m-ultiplier, while the right hand side represents a transfer of the 
accumulated result to the store." The existence of two accumulators 
complicated matters; for example, after the multiplication in lines 8 
and 9 "the upper accumulator was considered relevant (in the -» y ), idiile 
else'vdiere only the lower accumulator was used. The expression " +a+bc " 
meant "load the lower accumulator with a , then add it to the double 
length product be ", while " +bc+a " meant "form the double length 
product be , then add a into the upper half of the acciimulator" . 
Expressions like + ab + cd + ef were allowed, but not products of three 
or more quantities; and there was no provision for parentheses. The 
language was designed to be used with the 52-character Teleprinter code, 
where -► was substituted for " . 

We have remarked that Glennie's papers have never been published; 
this may be due to the fact that his employers in the British atomic 
weapons project were in the habit of keeping documents classified. 
Glennie's work was, however, full of choice quotes, so it is interesting 
to repeat several more remarks he made at the time: 

There are certain other rules for punching that are merely a 
matter of common sense, such as not leaving spaces in the middle 
of words or misspelling them. I have arranged that such accidents 
will cause the input programme to exhibit symptoms of distress . . . 
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This consists of the programme coming to a stop and the machine 
making no further moves. 

[The programme] is quite long but not excessively long, about 
750 orders. ... The part that deals vfith the translation of the 
algebraic notation is the most intricate programme that I have ever 
devised ... [but the number of orders required] is a small 
fraction of the total, about ll<-0. 

My experience of the use of this method of programming has 
been rather limited so far, but I have been much impressed by 
the speed at which it is possible to make up programmes and the 
certainty of gaining correct programmes. ... The most important 
feature, I think, is the ease with which it is possible to read 
back and mentally check the programme. And of course on such 
features as these will the usefulness of this type of programming 
be judged. [GL 52] 

At the beginning of the user's manual [GL 52'], he mentioned that 
"the loss of efficiency (in the sense of the additional space taken by 
routines made with AUTOCODE) is no more than about 10^." This remark 
appeared also in [BG 53, p. llj], and it may well be the source of the 
oft-heard opinion that compilers are "90^ efficient". 

On the other hand, Glennie ' s compiler actually had very little 
tangible impact on other users of the Manchester machine. For this reason, 
Brooker did not even mention it in his 1958 paper entitled "The Autocode 
Programs developed for the Manchester ISiiversity Computers" [BR 58]. 
This lack of influence may be due in part to the fact that Glennie was 
not resident at Manchester, but the primary reason was probably that his 
system did little to solve the really severe problems that programmers 
had to face, in those days of small and unreliable machines. An 
improvement in the coding process was not regarded then as a breakthrough 
of any importance, since coding was often the simplest part of a programmer's 
task. When one had to wrestle with problems of nimierical analysis, scaling, 
and two-level storage, meanwhile adapting one's program to the machine's 
current state of malfunction, coding itself was quite insignificant. 
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Thus -wherL Glennie mentioned his system in the discussion following 
[MG 53]) it met with a very cool reception. For example, Stanley Gill's 
comment reflected the prevailing mood: 

It seems advisable to concentrate less on the ability to write, 
say 

+ a + b+ab -»c 
as it is relatively easy for the programmer to write 

A a 

A b 

H a 

V b 

T c . [MG 53, p. 79] 

Nowadays we would say that Gill had missed a vital point, but in I955 
his remark was perfectly true. 

Some 13 years later, Glennie had the following reflections [GL 65]: 

[The compiler] was a successful but premature experiment. 
Two things I believe were wrong: (a) Floating-point hardware 
had not appeared. This. meant that most of a programmer's effort 
was in scaling his calculation, not in coding, (b) The climate 
of thought was not right. Machines were too slow and too small. 
It was a programmer's delight to squeeze problems into the 
smallest space. ... 

I recall that automatic coding as a concept was not a novel 
concept in the early fifties. Most knowledgeable programmers 
knew of it, I think. It was a well known possibility, like the 
possibility of computers playing chess or checkers. ... [Writing 
the compiler] was a hobby that I undertook in addition to my 
employers' business: they learned about it afterwards. The 
compiler , . , took about three months of spare time activity to 
complete. 
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Early American "Compilers". 

None of the authors we have mentioned so far actually used the word 
"compiler" in connection with what they were doing; the terms were 
automatic coding, codification automatique , Rechenplanfertigung . In fact 
it is not especially obvious to programmers today why a compiler should be 
so called. We can understand this best by considering briefly the other 
types of programming aids that were in use during those early days. 

The first important programming tools to be developed were, of course, 
general-purpose subroutines for such commonly needed processes as 
input-output conversions, floating-point arithmetic, and transcendental 
functions. Once a library of such subroutines had been constructed, there 
was time to think of further ways to simplify programming, and two 
principal ideas emerged: (a) Coding in machine language could be made 
less rigid, by using blocks of relocatable addresses [WH 50]. This idea 
was extended by M. V. Wilkes to the notion of an "assembly routine", able 
to combine a number of subroutines and to allocate storage [WW 51? PP- 27-32]; 
and Wilkes later [WI 52, WI 53] extended the concept further to include 
general symbolic addresses (i.e., not simply relative to a small number of 
origins). For many years these were called "floating addresses". Similar 
developments in assembly systems occurred in America and elsewhere; 
ef. [RO 52 J. \Jo J An artificial machine language or pseudo-code was 
devised, usually providing easy facilities for floating-point arithmetic 
as if it had been built into the hardware. An "interpretive routine" 
(sometimes called "interpretative" in those days) would process these 
instructions, emulating the hypothetical computer. The first interpretive 
routines appeared in programming' s first textbook, by Wilkes, Wheeler, 
and Gill [WW ^1, pp. 3^-37, 7U-77, l62-l6ij-] ; the primary aim of this book 
was to present a library of subroutines and the methodology of their use. 
Shortly afterwards a refined interpretive routine for floating-point 
calculation was described by Brooker and Wheeler [BW 53]? including the 
ability for subroutines nested to any depth. Interpretive routines in 
their more familiar compact form were introduced by J. M. Bennett (cf. 
[WW 51, Preface and pp. l62-l6l4-], [BP 52]); the most influential was 
perhaps John Backus 's IBM 7OI Speedcoding System [BA ^h, BH 5^]. As we 
have already remarked. Short Code was a different sort of interpretive 
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routine. The early history of library subroutines, assembly routines, 
and interpretive routines remains to be written; we have just reviewed 
it briefly here in order to put the programming language developments 
into context. 

During the latter part of 1951^ Grace Murray Hopper developed the 
idea that pseudo-codes need not be interpreted, they could also be 
expanded out into direct machine language instructions. She and her 
associates at IMIVAC proceeded to construct an experimental program 
which would do such a translation, and they called it a compiling routine . 

To compile means to compose out of materials from other documents. 
Therefore, the compiler method of automatic programming consists 
of assembling and organizing a program from programs or routines 
or in general from sequences of computer code which have been 
made up previously. [MO 5^^ p. 15] 

(See also [HO 55^ p. 22].) The first "compiler" in this sense, named A-0, 
was in operation in the spring of 1952, when Dr. Hopper spoke on the 
subject at the first ACM National Conference [HO 52]. Incidentally, 
M. V. Wilkes came up with a very similar idea, and called it the method of 
•"synthetic orders" [WI 52]; we would now call this a macro expansion. 

The A-O "compiler" was Improved to A-1 (January, 1955) and then 
to A-2 (August, 1953 ) 3 "the original implementors were Richard K. Ridgeway 
and Margaret H. Harper. Quite a few references to A-2 have appeared in 
the literature of those days [HM 53j HO 53^ HO 53', MO ^k, WA 5^+], but 
these authors gave no examples of the language itself. Therefore it will 
be helpful to discuss here the state of A-2 as it existed late in 1953, 
when it was first released to UNIVAC customers for testing [RR 53]. As 
we will see, the language was quite primitive by comparison with those 
we have been studying, and this is why we choose to credit Glennie with 
the first compiler although A-O was completed first; yet it is important 
to understand what was called a "compiler" in 195^, in order to appreciate 
the historical development of programming languages. 

Here is how TPK would have looked in A-2 at the end of 1953 : 
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Use of -working storage 



00 02 Oi^ 


06 


08 10 12 


ll^ to 3^ 56 38 1+0 


1+2 


-58 


10 5 i+OC 


-1 


«) 14- 5 


^0 ^° ^0 ^ y^y^y" t^t'^t''' 


temp 


storage 


Program 












. GMIOOO 


000002 


Read input 


and necessary constants from Tg 






ITEIVDI 


ws.ooo 










SERV02 


BLOCKA 










IRGOOO 


000000 










1. mmoo 


000001 










OOOlBO 


020216 


10.0 = i 








IRGOOO 


001000 











2. 


AMOO5I+ 


O3I+OI+O 


4- 


3 


ENAOl+0 


oiooi+o 


Vt = t- 


1+ 


AENO3I1 


012038 


^10 = y 


5 


AM0002 


038038 


5y = 7" 


6 


AAOOUO 


038038 


t'+y^ =j^^ 


7 


AS000i+ 


03801+0 


1+00-^"= t"" 


8 


OWWACO 


DEAOO3 





9. 



10. 

11. 



KOOOOO 
FOO9I2 
000000 
IRGOOO 
ICNOOO 



KDOOOO 
EOOIRG 
QPOICII 

oo8oi+o 

000010 



if t'-' > , go on to Op. 10 



OVIMOOO 
000188 
IRGOOO 



000001 
020238 
009000 



' AAATOO ALARGE AAAAAA AAAAAA' = y 



t _ ir/'x' 



yT0036 038000 Print i,y' 



GMMOOO 

OOOI9I+ 
IHGOOO 



000001 
200220 

011000 



Move 20 -words from WSII+ to WSUo 
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12. 


GMMOOO 


000001 






000222 


200196 


Move 20 words from WSi<-0 to WSI6 




IRGOOO 


012000 




15. 


ALL012 


FOOOT/ 






IRGOOO 


015056 


Replace i by i+(-l) and go to Op. 2 




2RG000 


000057 


if 1^-1, otherwise go to Op. l^i- 




3RG000 


000006 






i+RGOOO 


000007 






5RG000 


000006 






6RGO00 


000007 






ICWOOO 


000002 






2CN000 


OOOOll^ 






IRSOOO 


000056 






2RS000 


000057 




Ik. 


OWNACO 


DEA002 






810000 


820000 


• 

Rewind tapes 1 and 2, and halt. 




900000 


900000 






IRGOOO 


014000 





j^jZiENDA IWO.-^ 



There were 60 words of working storage, and each floating-point number 
used two words. These working storages were usually addressed by numbers 
00 , 02 , . . . , 58 , except in the GMM instruction (move generator) -vAien 
they were addressed by I80 , I82 , ... , 258 respectively; see operations 
1^ 9, 11, and 12. Since there was no provision for absolute val ue, 
operations 2 and 5 of this program find Vja^Ql by computing Va, „ . 
(The A-2 compiler would replace most operators by a fully exrpanded subroutine, 
in line; this subroutine would be copied anew each time it was requested, 
unless it was one of the four basic floating-point arithmetic operations.) 
Since there was no provision for subscripted variables, operations 11 
and 12 shift the array elements after each iteration. 

Most arithmetic instructions were specified with a three-address 
code, as shown in operations 2 thru 7. But at this point in the development 
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of A-2 there was no way to test the relation " > " without resorting 
to machine language -- only a test for equality was built in -- so 
operation 8 specifies the necessary UNIVAC instructions. (The first 
word in operation 8 says that the following 005 lines contain UNIVAC 
code. Those three lines extract (E) the sign of the first nimeric 
argument (lEG) using a system constant in location 912 , and if it 
was positive they instruct the machine to go to program operator ICN . 
The next two lines say that IRG is to be t" (working storage kO ), 
and that ICN is to be the address of operation 10. The " 008 " in the 
IRG specification tells the compiler that this is operation 8; such 
redimdant information was checked at compile time. Note that the 
compiler woiad substitute appropriate addresses for IRG and ICW 
in the machine language instructions. Since there was no notation 
for " lEG + 1 ", the programmer had to supply ten different parameter 
lines in operation I5 • 

By 1955^ A-2 had become more streamlined, and the necessity for 
OWN CODE in the above program had disappeared; see [PR 55] for a description 
of A-2 coding, vintage 1955. (Another paper [TH 55] also appeared at that time, 
presenting the same example program.) Operations 7 and the following of 
the above program could now be replaced by 



7 . 0^:0038 OOivOOO 
ICNOOO 000009 

8. QUOO38 038000 
ICNOOO 000010 

9. MVOOO8 001038 

10. YT0036 038000 



11. 
12. 

15. 



lU. 



MVOOli^ OIOOI4-O 

MVOOUO 010016 

AALO36 006006 

ICNOOO 000002 

2CN000 OOOOII+ 

RWS120 000000 

END AGO DINGAA 



To Op. 9 if y' > Uoo 
Go to Op. 10 



\ Same meaning as before, but new syntax. 
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Laning and Zlerler. 

Grace Hopper was particularly active as a spokesperson for 
automatic programming diiring the 1950' s; she went barnstorming 
throughout the country, significantly helping to accelerate the 
rate of progress. One of the most important things she 
accomplished was to help organize two key symposia on the topic, in 
195 ij- and 1956, under the sponsorship of the Office of Naval Research. 
These symposia brought together many people and ideas at an important 
time. (On the other hand, it must be remarked that the contributions 
of Zuse, Curry, Burks, Mauchly, B'dhm, and Glennie were not mentioned at either 
symposium, and Rutishauser' s work was cited only once — not quite 
accurately [GO 5h, p. 76]. Communication was not rampant I) 

In retrospect, the biggest event of the 195^ symposium on automatic 
programming was the announcement of a system that J. Halcombe Laning, Jr. and 
Niel Zierler had recently implemented for the Whirlwind computer at M. I.T. 
However, the significance of that announcement is not especially evident 
from the published proceedings [WA 5^]^ 9jfo of which are devoted to 

"compilers". We know of the impact mainly from Grace Hopper's introductory 
remarks at the 1956 synrposiim, discussing the past two years of progress: 

A description of Laning and Zierler' s system of algebraic 
pseudocoding for the Whirlwind computer led to the development 
of Boeing's BACAIC for the 7OI, FORTRAN for the 70I;, AT-3 for 
the Iftiivac, and the Purdue System for the Datatron and indicated 
the need for far more effort in the area of algebraic translators. 
[HO 36] 

A clue to the importance of Laning and Zierler' s contribution can also 
be foixnd in the closing pages of a paper by John Backus and Harlan Herrick 
at the 195^*- symposium. After describing IBM 70I Speedcoding and the 
tradeoffs between interpreters and "compilers", they concluded by 
speculating about the futiire of automatic programming: 
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A programmer might not be considered too unreasonable if he 
were willing only to produce the formulas for the numerical 
solution of his problem, and perhaps a plan showing how the 
data was to be moved from one storage hierarchy to another, 
and then demand that the machine produce the results for his 
problem. No doubt if he were too insistent next week about 
this sort of thing he would be subject to psychiatric 
observation. However, next year he might be taken more 
seriously. [BH 5^] 

After listing numerous advantages of high-level languages, they said: 
"Whether such an elaborate autooiatic-prograrmning system is possible 
or feasible has yet to be determined." As we will soon see, the system 
of Laning and Zierler proved that such a system is indeed possible. 
Brief mention of their system was made by Charles Adams at the 
symposium [AL 5h]; but the full user's manual [LZ 5U] ought to be 
reprinted some day because their language went so far beyond what had 
been implemented before. The programmer no longer needed to know much 
about the computer at all, and the user's manual was (for the first time) 
addressed to a complete novice. Here is how TPK would look in their 
system: 



1 


V W= (input). 


2 


i=0. 


1 


1 j =i+l. 


h 


aji =v J, 


^ 
^ 


■1 -1 


6 


e=i-10.5. 


1 


CP 1, 


8 


i=10. 


9 ^ 


5 y =F^(F^^(a i))+5(a i)^. 


10 


e =y-i<-00. 


11 


CP 3, 


12 


z=999. 


13 


PRINT i, z. 
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ll^ 




SP i^, 


15 


5 


PRINT i,y. 


16. 


k 


i =1-1, 


17 




e=-0.5-±, 


18 




CP 2, 


19 




STOP 



The program was typed on a Flexowriter -which punched paper tape 

and had a fairly large character set (including both upper aad lower 

1 9 
case letters); at M.I.T. they also had superscript digits , ,..-, 

and a vertical line I . The language used the vertical line to 

indicate subscripts ; thus the " ^{a.\iy " on line 9 means 5a^ . 

A programmer would insert his eleven input values for the TPK 

algorithm into the place shown on line 1; then they would be converted 

to binary notation and stored on the magnetic drijm as variables 

V, ,Vp, ...,v, ^ . If the nimibers had a simple arithmetic pattern, aa 

abbreviation coiHd also be used; e.g., 

v'ji'i = J. v.»>> "- \''-^ } V*> \-^ I > '-^ 

would set (v^, ...,v^^) - (1, 1.5 , 2 ,2.25 , 2.5 ,2.75 ,3 ,5-25 ,5-5 , ^^.5 , 5-5) 
If desired, a special code coiild be punched on the Flexowriter tape in 
line 1, allowing the operator to substitute a data tape at that point 
before reading in the rest of the source program. 

Lines 2 thru ']_ are a loop which moves the variables v.,, "-t^YL '^^^^ 
the drum to variables a^, •••,a^o ^'^ ^or^, (All variables were in core 
unless specifically assigned to the drum by an ASSIGN or JN instinction. 
This was an advanced feature of the system not needed in small problems.) 
The only thing that isn't self-explanatory about lines 2 thru J_ is line Jy 
" CP k, " means "if the last expression computed was negative, go to the 
instruction labeled k". 

In line 9, F denotes square root and F"^ denotes absolute value. 
In line lU, " SP " denotes an unconditional jtmip. (CP and SP were the 
standard mnemonics for jumps in Whirlwind machine language.) Thus, except 
for control statements -- for which there was no existing mathematical 
convention -- Laning and Zierler's notation was quite easy to read. 



57 



Their expressions featured normal operator precedence, as well as 
implied multiplication and exponentiation; and they even included a 
built-in Runge - Kutta mechanism for integrating a system of differential 
equations if the programmer wrote formulas such as 

Dx = y + 1, 
Dy = -X, 

where D stands for d/dt I Another innovation, designed to help 
debugging, was to execute statement number 100 after any arithmetic 
error message, if 100 was a PRINT statement. 

According to [LM 70]^ Laning first wrote a prototype algebraic 
translator in the summer of 1952. He and Zierler had extended it to a 
usable system by May, 1955^ when the Whirlwind had only 102U l6-bit 
words of core memory in addition to its dr\mi. The version described in 
[LZ 5^] utilized 20if8 words and drum, but earlier compromises due to 
such extreme core limitations caused it to be quite slow. The source 
code was translated into blocks of subroutine calls, stored on the drum, 
and after being transferred to core storage (one equation's worth at a 
time) these subroutines invoked the standard floating-point interpretive 
routines on the Whirlwind. 

The use of a small number of standard closed subroutines has 
certain advantages of logical simplicity; however, it also often 
results in the execution of numerous unnecessary operations. 
This fact, plus the frequent reference to the drum required in 
calling in equations, results in a reduction of computing speed 
of the order of magnitude of ten to one from an efficient computer 
program. [AL ^h, p. 6k] 

From a practical standpoint, those were damning words. Laning recalled, 
eleven years later, that 

This was in the days when machine time was king, and people-time 
was worthless (particularly since I was not even on the Whirlwind 
staff). ... [The program] did perhaps pay for itself a few times 
when a complex problem required solutions with a twenty-four 
hour deadline. [LA 65] 
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In a recent search of his files, Lanlng fotind a listing of the 
Whirlwind compiler's first substantial application: 

The problem addressed is that of a three-dimensional lead 
pursuit course flowi by one aircraft attacking another, including 
the fire control equations. What makes this personally interesting 
to me is tied in with the fact that for roughly five years previous 
to this time the [M. I.T. Instrumentation] Lab had managed and 
operated the M. I.T. Rockefeller Differential Analyzer with the 
principal purpose of solving this general class of problem. 
Unfortunately, the full three dimensional problem required more 
integrators than the RDA possessed. 

My colleagues who formulated the problem were very skeptical 
that it could be solved in any reasonable fashion. As a challenge, 
Zierler and I sat down with them in a 2-1/2 hour coding session, 
at least half of which was spent in defining notation. The tape 
was punched, and with the usual beginner's luck it ran successfully 
the first time I Although we never seriously capitalized on this 
capability, for reasons of cost and computer availability, my own 
ego probably never before or since received such a boost. [LA 76] 

The lead-piirsuit source program consisted of 79 statements, including 29 
which merely assigned initial data values, and also including seven uses 
of the differential equation feature. 

Laning describes his original parsing technique as follows: 

Nested parentheses were handled by a sequence of generated 
branch instructions (sp). In a one-pass operation the symbols 
were read and code generated a symbol at a timej the actual 
execution sequence used in-line sp orders to hop about from 
one point to another. The code used some rudimentary stacks, 
but was sufficiently intricate that I didn't understand it without 
extreme concentration even when I wrote it. ... StrucVored programs 
were not known in 19551 

The notion of operator precedence as a formal concept did not 
occur to me at tiie time; I lived in fear that someone would write 
a perfectly reasonable algebraic expression that my system would 
not analyze correctly. [LA 76] 
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Plans for a much exjianded Whirlwind compiler were dropped when the 
M. I.T. Instrtmentation Lab acqiiired its own computer, an IBM 650. 
Laning and his colleagues Philip C. Hankins and Charles P. Werner 
developed a compiler called MAC for this machine in 1957 and I958. 
Although MAC falls out of the time period covered hy our story, it 
deserves brief mention here because of its unusual three-line fonnat 
proposed by R. H. Battin c. 1956, somewhat like Zuse's original language, 
For example, the statement 



E 
M 
S 



3 

Y = SqRT(ABS(A )) +5 A 

I+l I+l 



would be punched on three cards. Althoijgh this language has not become 
widely known, it was very successful locally: MAC compilers were later 
developed for use with IBM 70U, 709, 709O and 56O computers, as well as 
the Honeywell h800 and HI8OO and the CDC 56OO. (See [LM 70].) "At the 
present time [I976], MAC and FORTRAN have about equal use at CSDL, " 
according to [LA 76]; here CSDL means C. S. Draper Laboratory, the 
successor to M.I.T. Instrumentation Lab. 

But we had better get back to our story of the early days. 

FORTRAN 0. 



During the first part of 195^^ John Backus began to assemble a group 
of people within IBM to work on improved systems of automatic programming 

at the ONR meeting in May, Backus wrote to Laning that "our formulation 
of the problem is very similar to yours: however, we have done no 
programming or even detailed planning." Within two weeks, Backus and his 
co-workers Harlan Herrick and Irving Ziller visited M.I.T. in order to see 
the Laning/ zierler system in operation. The big problem facing them was 
to implement such a language with suitable efficiency. 
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At that time^ most programmers wrote symbolic machine 
instructions exclusively (some even used absolute octal or 
decimal machine instructions). Almost to a man, they firmly 
believed that any mechanical coding method would fail to apply 
that versatile ingenuity which each programmer felt he possessed 
and constantly needed in his work. Therefore, it was agreed, 
compilers could only turn out code which would be intolerably 
less efficient than human coding (intolerable, that is, unless 
that inefficiency could be buried under larger, but desirable, 
inefficiencies such as the programmed floating-point arithmetic 
usually required then) . ... 

[Our development group] had one primary fear. After working 
long and hard to produce a good translator program, an important 
application might promptly turn up which would confirm the views 
of the sceptics: ... its object program woixLd run at half the 
speed of a hand-coded version. It was felt that such an occiirrence, 
or several of them, would almost completely block acceptance of 
the system. [BH 6*+] 



By November of 195U, Backus 's group had specified "The IBM Mathematical 
FORmula TRAEslating system, FORTRAN " . (Almost all the languages we shall 
discuss from now on had acronyms.) The first paragraph of their report 
[IB 5^1-] emphasizes that previous systems had offered the choice of easy 
coding and slow execution or laborious coding and fast execution, but 
FORTRAN would provide the best of both worlds. It also places specific 
emphasis on the IBM 70^1 ; machine independence was not a primary goal, 
although a concise mathematical notation "which does not resemble a machine 
language" was definitely considered important. Furthermore they stated 
that "each future IBM calculator should have a system similar to FORTRAN 
accompanying it." 

It is felt that FORTRAN offers as convenient a language for stating 
problems for machine solution as is now known. . . . After an hour 
course in FORTRAN notation, the average programmer can fully under- 
stand the steps of a procedure stated in FORTRAN language without 
any additional comments. [IB 5^] 
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They went on to describe the considerable economic advantages of 
programming in such a language. 

Perhaps the reader thinks he knows FORTRAN already; it is certainly 
the earliest high-level language that is still in use. However, few 
people have seen the original I'^k version of FORTRAN, so it is 
instructive to study TPK as it might have been expressed in "FORTRAN 0" : 



1 




DIMENSIOH A(ll) 


2 




READ A 


5 


2 


DO 5^8,11 J = 1,11 


k 


5 


i = n-j 


5 




Y = SQRT(ABS(a(I+1) ) ) + 5*A(I+1)**3 


6 




IF (1+00. > = Y) 8,1+ 


1 


1+ 


PRINT 1,999. 


8 




GO TO 2 


9 


8 


PRINT I,Y 


10 


11 


STOP 



The READ and PRINT statements do not mention any FORMATS, although an 
extension to format specification was contemplated [p. 26]; programmer- 
defined functions were also under consideration [p. 27]. The DO statement 
in line 5 means, "Do statements 5 thru 8 and then go to 11"; the 
abbreviation " DO 8 J = l, 11 " was also allowed at that time, but the 
original general form is shown here for fun. Note that the IF statement 
was originally only a two-way branch (line 6); the relation could be = , 
> , or >= . On line 5_ we note that function names need not end in F ; 
they were required to be at least three characters long, and there was 
no maximxam limit (except that expressions could not be longer than 750 
characters). Conversely, the names of variables were restricted to be 
at most two characters long at this time; but this in itself was an 
innovation, FORTRAN being the first language in which a variable's 
name could be larger than one letter, contrary to established 
mathematical conventions. Note that mixed mode arithmetic 
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was allowed, the compiler was going to convert " 5" to " 5.0" in line 5_. 
A final curiosity about this program is the GO TO statement on line 8; 
this did not begin the DO loop all over again, it merely initiated the 
next iteration. 

Several things besides mixed-mode arithmetic were allowed in FORTRAN 
but withdrawn during implementation, notably (a) subscripted subscripts 

of the form N*I+J were allowed, provided that at least two of the 
variables N, I, J were declared to be "relatively constant" (i.e., 
infrequently changing); (c) a RELABEL statement was intended to permute 
array indices cyclically without physically moving the array in storage. 
For example, " RELABEL A(3) " was to be like setting 
(A(1),A(2),A(5), ...,A(n)) - (a(3 ),..., A(n),A(l),A(2) ) . 

Incidentally, statements were called formulas throughout the 195^ 
document; there were arithmetic formulas, DO formulas, GO TO formulas, 
etc. Similar terminology had been used by Bohm, while Laning and 
Zierler and Glennie spoke of "equations"; Grace Hopper called them 

'^jr^ — >. <.«v_^v^ii.s- m ^ -*— — - — ^— __ __^ _-_ - -.i ■-■— --- _ --^^-_^- — -----^ _ — — ----.-. -^ .'..-■---'. . ^^ ^ — ^ ^ _, ^ 

there is a FORTRAN language and a FORTRAN system, but not a FORTRAN 
compiler. 

The FORTRAN dociment represents the first attempt to define the 
syntax of a programming language rigorously; Backus 's important notation 
[BA 59] which eventually became " BNF" [KN 6h] can be seen in embryonic 
form here. 

With the FORTRAN language defined, it "only" remained to implement 
the system. It is clear from reading [IB 5^] that considerable plans 
had already been made towards the implementation; however, the full job 
took 2.5 more years (l8 man-years), so we shall leave the IBM group at 
work while we consider other developments. 

Brooker ' s Autocode . 

Back in Manchester, R. A. Brooker introduced a new type of Autocode for 
the Mark I machine. This language was much "cleaner" than Glennie' s, 
being nearly machine- independent and using programmed floating-point 
arithmetic, but it allowed only one operation per line, there were few 
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mnemonic names, and there was no way for a user to define subroutines. 
The first plans for this language, as of March 195^1-, appeared in [BR 55], 
and the language eventually implemented [BR %, pp. 155-15?] was almost 
the same. Brooker's emphasis on economy of description was especially 
noteworthy: "Vlhat the author aimed at was two sides of a foolscap sheet 
with possibly a third side to describe an example. " [BR 55] 

The floating-point variables in Brooker's Maxk I Autocode are called 
vl, v2, ... and the integer variables — which may be used also as 
indices (subscripts) — are called nl,n2, ... . The Autocode for TPK is 
easily readable with only a few auxiliary comments, given the memory 

, i = n^ : 



assignments a. = v, . , y = v. 



12 



1 


nl 


= 1 




vnl 


= I 




nl 


= nl+1 




J 1.11 


> nl 




nl 


= 11 


2 


* n2 


= nl-1 




vl2 


= vnl 




J3.V12 


> 0-0 




vl2 


= 0.0-V12 


3 


vl2 


= Fl(vl2) 




vl3 


= 5-0(8) vnl 




vl3 


= vnl(8)vl3 




vl3 


= vnl®vl3 




vl2 


= vl2 + vl3 




_• 1, — -1 r-. 


> 400 • 




* vl2 


= vl2 




J5 




h 


* vl2 


= 999-0 


5 


nl 


= nl-l 




j2,nl : 


> 
H 




(Jl) 



sets n, = 1 

reads input into v 



n 



1 



jumps to 1 if n < 11 



prints i = n -1 



sets V3_2 = |v^2 I 



(^2 ='^1^1. 



(y = f(a.)) 



prints y 

prints 999 

tests for last cycle 

halt 

starts programme 



Gh 



The final instruction illustrates an interesting innovation: An 
instruction or group of instructions in parentheses was obeyed 
immediately, rather than added to the program. Thus " (jl) " Jumps 
to statement 1. 

This language is not at a very high level, but Brooker's main 
concern was simplicity and a desire to keep information flowing 
smoothly to and from the electrostatic high-speed memory. Mark I's 
electrostatic memory consisted of only 512 20-bit words, and it was 
necessary to make frequent transfers from and to the 32K-word drum; 
floating-point subroutines could compute while the next block of 
program was being read in. Thus two of the principal difficulties 
facing a programmer — scaling and coping with the two-level store — 
were removed by his Autocode system, and it was heavily used. For 
example : 

Since its completion in 1955 the Mark I Autocode has been used 
extensively for about 12 hours a week as the basis of a computing 
service for which customers write their own programs and post 
them to us. [BR 58, p. l6] 

Gary E, Felton, who developed the first Autocode for the Ferranti 
PEGASUS, says in [FE 60] that its specification "clearly owes much to 
Mr. R. A, Brooker." Incidentally, Brooker's next Autocode (for the 
Mark II or 'Mercury' computer, first delivered in 195?) was considerably 
more ambitious; see [BR 58, BR 58', BR 60]. 
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Russian programming Programs. 

Work on automatic programming began in Russia at the Mathematical 
Institute of the Soviet Academy of Sciences, and at the Academy's 
computation center, which original 1 y was part of the Institute of Exact 
Mechanics and Computing Technique. The early Russian systems were 
appropriately called Programming Programs [Prograiraniruioshchye Programmy] 
— or TTlT for short. An experimental program TlTr-l for the STRELA computer 
was constructed by E. Z. Liubimskii and S. S. Kamynin during the summer 
of 195^; and these two authors, together with M. R. Shura-Bura, 
E. L. Lukhovitskaia, and V. S. Shtarkman, completed a production compiler 
called TTTT-2 in Febinary, 1955. This ccampiler is described in [KL 58]. 
Meanvftiile, A. P. Ershov began in December 195^ to design another programming 
program, for the BESM computer, with the help of L. N. Korolev, 
L. D. Panova, V. D. Poderiugin and V. M. Kurochkin; this compiler, called 
simply nrr, was completed in March, I956, and it is described in Ershov' s 
book [ER 58]. A review of these developments appears in [KO 58]. 

In both of these cases, and in the later system TTll'-3 completed in I957 
(see [ER 58']), the language was based on a notation for expressing 
programs developed by A. A. Liapunov in 1953. Liapunov's operator 
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schemata [LJ 58] provide a concise way to represent program structure 
in a linear manner; in some ways this approach is analogous to 
the ideas of Curry we have already considered, but it is somewhat 
more elegant and it became widely used in Russia. 

Let us consider first how the TPK algorithm (exclusive of input- 
output) can be described in TTiT-S. The overal-l operator sclieme for tlie 
program would be written 

\ J Z2 ^ Ri, r A5 n Ag R^ L ^ N^ r J \o n \i Fi2 Ri3 L N^^ . 

±9 ±0 ( d. 

n 

Here the operators are numbered 1 thru lU ; and j , | mean 

m 

respectively " go to operator n if true, go to operator m if false ", 
i 

while I , [ are the corresponding notations for "coming from operator i" 

i 

This operator scheme was not itself input to the programming program 

explicitly, it would be kept by the programmer in lieu of a 

flowchart. The details of operators would be written separately and 

input to Trn'-2 after dividing them into operators of types R (relational), 

A (arithmetic), Z (dispatch), F (address modification), 

(restoration), and N (nonstandard, i.e., machine language). In the 

above case, the details are essentially this: 

[if p^ is true go to 6 else to 5] 

[if p is true go to 8 else to 10] 

[if p is true go to l)\ else to 2] 

[0 < x] 

[i+00 < y] 

[i < 0] 

[10 = i, i.e., set i equal to 10] 

[a^ = x] 

[0-x = x] 
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\- 


?]_; 6, 5 


^• 


Pg; 8, 10 


Hy 


Vy 1^, 2 


pr 


C3 <V2 


^2- 


^<"3 


Vy 


^6<^3 


h- 


%=\ 


h' 


\=^2 


A^. 


C3-V2 = v^ 



Ag. (/ V2)+(c^-v^.v^.v^) = v^ [(/x)+(5.a^.a^.a^) =y] 

[i =b^, 999 = c^] 

[i = b^, y = c^] 

[i-1 = 1] 

[dispatch a^ to special cell, in operators 5 thru 6] 

[modify addresses depending on parameter i, in 
operators 2 thru 10] 

[go to operator 11] 

[stop] 

Dependence on parameter v^. "V", ,v,, -1; v. , v^-, +2 

[when i changes, v goes down by 1, v. thru v go up 2] 



Aq. 


\ = \' ^2 


-"5 


ho- 


^6 = ^V ^3 


-^5 


hv 


^6-^1 = ^6 




:^. 


v^; 3, 6 




^12- 


vg; 2, 10 




\' 


BP n 




NiV 


OST 





c^. 


.1-10^ 


[1] 


^2- 


.999-10^ 


[999] 


<^5- 







<=u- 


.i^.io^ 


[400] 


c^. 


O-lQ-^ 


[5] 



Working cells: 100,119 [compiled program can use locations IOO-II9 for temp 

storage] 

[initial address of a.] 

1 

[address of x] 

[address of y] 

[initial address of b.] 

1 

[initial address of c] 
[address of i] 

Operator 1 initializes i , then operators 2 thru I3 are the loop on i . 
Operator 2 moves a^ to a fixed cell, and makes sure that operators 5 
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^1- 


130 


^2- 


131 


^3- 


132 


V),. 


133 


V5. 


15U 


v^- 


15 i^ 



thru 6 use this fixed cell; this programmer- supplied optimization 
means that fewer addresses in instructions have to be modified -when 
i changes. Operators J thru 5 set x = |a. | , and operator 6 sets 
y = f(a^) • (Note the parentheses in operator 6; precedence was not 
recognized.) Operators 7 thru 10 store the desired outputs in memory; 
operators 11 and 12 decrease i and appropriately adjust the addresses 
of quantities that depend on i . Operators I5 and 14 control looping 
and stopping. 

The algorithms used in TnT-2 are quite interesting from the standpoint 
of compiler history; for example, they avoided the recomputation of 
common subexpressions within a single formula. They also produced 
efficient code for relational operators compounded from a series of 
elementary relations, so that, for example, 

(PlV(p2-p^) Vp^)-p^ VPg 
would be compiled as 




FALSE 



Ershov's TTTT language improves on 1171-2 in several respects, notably 
(a) the individual operators need not be numbered, and they may be 
intermixed in the natural sequence; (b) no address modification need 
be specified, and there is a special notation for loops; (c) the 
storage for variables is allocated semi -automatically; (d) operator 
precedence can be used to reduce the n\miber of parentheses within 
expressions. The TPK algorithm looks like this in TTTT: 
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1 Massiv a (11 iacheek) [declares an array of 11 cells] 

2 a„ = [address in array a] 

3 a. = -I'j+lO [address in array a depending on j] 

^ O: J V = *-'^ Jv =11 [information on loop indexes] 
^ n 3.0x1 Jtoxi 

5 0, 11, 10, 5, y, iK)0, 999, i [list of remaining constants and variables] 

6 (Ma, 080, 0, a^ ) ; (Mb, 0, 01, ) ; 

7 [ 10-J => i; / mod a . + 5 x a-< => y; 

0101 

8 R(y,0102; j {hOO,<x>))', 

0103 

9 1 Vyd i, ^ 0; Vyd 999, ^ 0; | ; 

0101 

10 ' I Vyd i, => 0; Vyd y, => 0; \ ]; STOP 

0102 0105 



After declarations on lines 1 thru 5_, the program appears here on lines 6 

thru 10. In 1717 each loop was associated with a different index name, and 

the linear dependence of array variables on loop indices was specified 

as in line 5; note that a. does not mean the j-th element of a , it 

J 

means an element of a which depends on j . The commands in line 6 

are BESM machine language instructions which read 11 words into memory 

starting at a^ . Line 7 shows the beginning of the loop on J , which 

ends at the " ] " on line 10; all loop indices must step by +1 . (The 

initial and final-plus- one values for the j loop are specified on line ^t-.) 

Line 8 is a relational operator which means, "If y is in the interval 

(1K)0,<») , i.e., if y > toO , go to label 0101 ; otherwise go to 0102 ." 

Labels were given as hexadecimal numbers, and the notation | indicates 

n 

the program location of label n . The " Vyd " instruction in lines £ an<i 

10 means convert to decimal, and " , => " means print. Everything 

else should be self-explanatory. 
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The Russian computers had no alphabetic input or output, so the 
programs written in TTTT-S and TtTT were converted into numeric codes. 
This was a rather tedious and intricate process, usually performed by 
two specialists who would compare their independent hand-transliterations 
in order to prevent errors. As an example of this encoding process, 
here is how the above program would actually have been converted into 
BESM words in the form required by TTlf. (The hexadecimal digits were 
written 0,1, . . .,9,0,1, . . .,5 . A 59-bit word in BESM could be represented 
either in instruction format, 

bbh bqhh bqhh bqhh 

where b denotes a binary digit (O or 1) , q a quaternary digit 
(O , 1 , 2 , or 3 ), and h a hexadecimal digit; or in floating-binary 
nimieric format, 

+ 2^ , hh hh hh hh 

where k is a decimal number between -32 and +31 inclusive. Both of 
these representations were used at various times in the encoding of a 
1TTT program, as shown below. ) 



Location Contents 



07 


000 


0000 0000 0000 


08 


000 


0000 0000 0013 


09 


000 


0000 0000 0015 


00 


000 


0000 0000 0012 


01 


000 


0000 0000 0025 


02 


000 


0000 0000 00U2 


03 


000 


0000 0000 0295 


ot 


000 


0000 0000 0215 


05 


000 


0000 0000 0255 


10 


015 


0000 oooi 0000 


11 


000 


1001 0000 0000 


12 


2\ 


00 00 00 00 


13 


2^ 


Ik 00 00 00 


Ik 


000 


0015 0016 0000 



Meaning 

no space needed for special subroutines 

last entry in array descriptor table 

first entry for constants and variables 

last entry for constants and variables 

base address for encoded program scheme 

last entry of encoded program 

base address for "block 7 " 

base address for "block a " 

base address for "block p " 

a = array of size 11 

coefficient of -1 for linear dependency 

a^ =- relative to a 

a. = -l'J+10 relative to a 

J 

j = loop index from to 11 
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Location 


Contents 




Meaning 


15 


2~^^, 00 


00 00 00 





16 


2\ 


10 


00 00 00 


11 


17 


00 


00 00 00 


10 


18 


2'> 


00 


00 00 00 


5 


19 
10 


2^, 
2^° 


28 

, 59 


00 00 00 
20 00 00 


1+00 

999 


11 


000 


0000 


0000 0000 


1 


12 


000 


0000 


0000 0000 


y 


50 


016 


oo8o 


0000 0012 


(Ma , 080 , , a 


51 


017 


0000 


oooi 0000 


(Mb , , 01 , 0) 


52 


018 0011+ 


0000 0000 


10 - j ^ 


55 


2°, 


17 oi 


^ 11+ 08 


5i^ 


2°, 


11 55 52 15 


i y mod a . 

+ 5 X a, 
5 '^ 

^ y 


55 


2^ 


05 i£ 


i 09 15 


56 


2°, 


o5 o£ 


! 15 00 


57 

58 


018 
008 


0000 

0019 


0012 0102 
0000 0101 


R(y, 0102; 
0101 

(1+00,0=)) 


59 


018 

2°, 


0101 

5h il 


0000 0000 
■ 07 00 


1 


50 


0101 
Vyd i ,=> 


51 
52 


2°, 
Oil 


5U ic 

0000 


> 07 00 

0000 0105 


Vyd 999 ^=» 
0105 


55 


018 
2°. 


0102 
5h 11 


0000 0000 
■ 07 00 




5Ji 


0102 
Vyd i ,^ 


55 


2^ 


Sk 12 


! 07 00 


Vyd y ,-> 


ko 


018 
015 


0103 
1555 


0000 0000 

1555 1555 




i^l 


0105 
] 


k2 


015 


0000 


0000 0000 


STOP 



•0^ 
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The BESM had 102 li- words of core memory, plus some high-speed 
read-only memory, and a magnetic drucm holding 5 x 102^4- words. The TTlT 
compiler worked in three passes (formulas and relations, loops, final 
assembly), and it contained a total of 1200 instructions plus 150 
constants. Detailed specifications of all its algorithms were published 
in [ER 58]j Ershov was aware of Rutishauser' s work [p. ^], but he gave 
no other references to non-Russian soxixces. 

A Western Development. 

Computer professionals at the Boeing Airplajie Company in Seattle, 
Washington, felt that "In this jet age, it is vital to shorten the time 
from the definition of a problem to its solution." So they introduced 
BACAIC, the Boeing Airplane Company Algebraic Interpretive Computing 
system for the IBM 701 computer. 

BACAIC was an interesting language and compiler developed by 
Mandalay Grems and R. E. Porter, who began work on the system in the 
latter part of 195^; they presented it at the Western Joint Computer 
Conference held in San Francisco, in Februarvi 1956 fGP 561, Although 
the " I" in BACAIC stands for "Interpretive", their system actually 
translated algebraic expressions into machine language calls on 
subroutines, with due regard for parentheses and precedence, so we 
would now call it a compiler. 

The BACAIC language was unusual in several respects, especially in 
its control structure which assumed one-level iterations over the entire 
program; a program was considered to be a nearly straight-line computation 
to be applied to various "cases" of data. There were no subscripted 
variables; however, the TPK algorithm could be performed by inputting 
the data in reverse order using the following program: 
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1. 


I-K1*I 






2. 


X 






3. 


WHW X GRT K2 


USE 5 




k. 


K2-X*2 






5. 


SET X+ ig . 


X PWR 


Kk 


6. 


WHN 5 GRT K5 


USE 8 




7. 


TEN 9 






8. 


K6^5 






9. 


TAB I 5 







Here " *" is used for assignment, " ." for multiplication; variables 
are given single-letter names (except K), and constants are denoted 

The above program is to be used with the following 

K5 = 5.0 Ki+ = 5.0 K5 = Uoo.o k6 = 999.0 



by KL thru K99 . 


The abov 


input data: 




Case 1. Kl = 1.0 


K2 = 0.0 


I = 11.0 


^ = ^0 


Case 2. X = a 




Case 3 . X = an 




• • • 

Case 11. X = a^ . 





Data values are identified by name when input; all variables are zero 
initially, and values carry over from one case to the next unless changed. 
For example, expression 1 means " I-l -. I ", so the initial value I = 11 
needs to be input only in Case 1. 

Expressions 2, 3, h ensure that the value of expression 2 is the 
absolute value of X when we get to expression 5. (The " 2 " in 
expression k means expression 2, not the constant 2 .) Expression 5 
therefore has the value f (X) . 

A typical way to use BACAIC was to print the values associated with 
all expressions 1,2, ... ; this was a good way to locate errors. 
Expression 7 in the above program is an unconditional jump; expression 9 
says that the value of I and expression 5 should be printed. 

The BACAIC system was easy to learn and to use, but the language 
was too restrictive for general-purpose computing. One novel feature 
was its "check-out mode", in which the user furnished hand- calculated data 
and the machine would print out only the discrepancies it found. 



Ih 



According to [BE 5?], BACAIC became operational also on the 
IBM 650 computer, in August of 195 6. 

Kompilers. 

Another independent development was taMng place almost slmToltaneously 
at the Iftiiversity of California Radiation Laboratory in Livermore, 
California; this work has apparently never been published, except as an 
internal report [EK 55]. In 1954, A. Kenton Elsworth began to experiment 
with the translation of algebraic equations into IBM 7OI machine language, 
and called his program KOMPILER 1; at that time he dealt only with 
individual formulas, without control statements or constants or input/ output, 
Elsworth and his associates Robert Kuhn, Leona Schloss, and Kenneth Tiede 
went on to implement a working system named KOMPILER 2 during the following 
year. This system is somewhat similar in flavor to Tnr-2, except that it 
is based on flow diagrams instead of operator schemata. They characterized 
its status in the following way: 

In many ways Kompiler is an experimental model; it is therefore 
somewiiau iimitea m applications. For example it is designed to 
handle only full-word data and is restricted to fixed-point 
arithmetic. At the same time every effort was made to design a 
workable and worthwhile routine: the compiled code shoiild approach 
very closely the efficiency of a hand-tailored code; learning to 
use it should be relatively easy; compilation itself is very 
fast. [EK 55] 

In order to compensate for the fixed-point arithmetic, special 
features were included to facilitate scaling. As we will see, this is 
perhaps KOMPILER 2's most noteworthy aspect. 

To solve the TPK problem, let us first agree to scale the numbers 
by writing 

A. = 2-l°a. , Y = 2-1% , I = 2-55 i ^ 

Furthermore we will need to use the scaled constants 

V = 5-2-5 , F = if00.2~l° , N = 999-2-l° , W = 1.2"55 , 
The next step is to draw a special kind of flow diagram for the program; 
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CABD constants 



CARD 



h 



0- /j^'. 2-5 + Va5 . 2^15 ^ Y 



c2:e>md 



< 



N = Y 



GH 



PRINT l,y 



2 :k 



I-1.2-55= J 





/ 



Read values of constants and initial 
value of I from a data card. 



Read A^, ...,A-„ from two more data cards. 



Calculate Y . 



Go to 6 if i|-00 > y . 



Set y to 999 . 



Print answer. 



Decrease i by 1 . 



Decrease address of A. by 2 
wherever it appears. 



Return to 3 if i > . 



Stop the machine. 
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The third step is to assign the data storage, for example as follows: 

61 = 1 , 63 s Y , 65 = V , 67 = F , 69 H N , 71 = W; 
81 = Aq , 83 = Aj_ , ... , 101 = Aj_Q . 

(Addresses in the IBM 7OI go by half words, but variables in KOMPILER 2 
occupy full words. Address 6I denotes halfwords 60 and 6I in the 
"second frame" of the memory.) 

The final step is to transcribe the flow-diagram information into 
a fixed format designated for keypunching. The source input to 
KOMPILER 2 has two parts: the so-called "flow diagram cards", one 
card per box in the flow diagram, and the "algebraic cards", one per 
complex equation. In our case the flow diagram cards are 



ICARD 


61 


2 


235 103 510 


310 135 


61 


2CAED 


81 


2 


310 310 310 310 


310 310 


310 95 Ih 


3CAI.C 


101 


8 


65 101 8 


63 




ItTRPL 


67 


63 6 








5 PLUS 


69 


63 








6PRNT 


61 


65 2 


1 35 10 






7MINS 


71 


61 61 








8DECR 


2 










9TRPL 


61 


Z 3 








lOSTOP 













and the algebraic cards are 

1*ACARD 
2^«-APRNT 
3 ASRTAABSA. -05+VA3 .+13=Y 

Here is a free translation of the meaning of the flow diagram cards: 

1. Read data cards into locations beginning with 6I in steps of 2 . The 

words of data are to be converted using respective scale codes 235,0,105, 
..,,0 ; stop reading cards after the beginning location has become 6I , 
i.e., immediately. (The scale code ddbb means to take the 10-digit 
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data as a decimal fraction, multiply by 10 , convert to binary, 
and divide by 2 .In our case the first input datvim vri.ll be 
punched as 1000000000 , and the scale code 255 means that this 
is regarded first as (10. 00000000 )j_q and eventually converted to 
(.00. ..01010) = 10«2~'^ , the initial value of I . The initial 
value of N , with its scale code JIO , would therefore be punched 
9990000000 . Up to seven words of data are punched per data card. ) 

2. Read data cards into locations beginning with 8I in steps of 2 . 
The words of data are to be converted using respective scale codes 
310,310, .. .,310 ; stop reading cards after the beginning location 
has become 95 • The beginning location shoiild advance by lit- 
between data cards (hence exactly two cards are to be read). 

5. Calculate a formula using the variables in the respective locations 
101 (which changes at step 8); 65; 101 (which changes at step 8); 
and 63. 

k. If the contents of location 67 minus the contents of location 63 
is nonnegative, go to step 6. 

5. Store the contents of location 69 in location 63 . 

6. Print locations 6I through 63, with 2 words per line and 1 line 
per block. The respective scale factors are 35 and 10 . 

7. Subtract the contents of location 7I from the contents of location 6I 
and store the result in location 6I . 

8. Decrease all locations referring to step 8 (cf . step 5 ) by 2 . 

9. If the contents of location 6I is nonnegative, go to step 3 • 

10. Stop the machine. 

The first two algebraic cards in the above example simply cause the 
library subroutines for card reading and line printing to be loaded with 
the object program. The third card is used to encode 



^Kl 



2"^ +VA? •2'^^ = Y 

1 



The variable names on an algebraic card are actually nothing but dummy 
placeholders, since the storage locations must be specified on the 
corresponding CALC card. Thus, the third algebraic card could also 
have been punched as 
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3 ASRTAABSX. -05+XX3 .+13=X 

without any effect on the result. 

KOMPILER 2 was used for several important production programs 
at Livermore. By 1959 it had been replaced by KOMPILER 3, a rather 
highly developed system for the IBM JOk which used three-line format 
analogous to that of MAC (but apparently designed independently). 



79 



A Declarative Language. 

During 1955 and 1956, E. K. Blum at the U. S. Naval Ordnance 
Laboratory developed a language of a completely different type. This 
language ADES (Automatic Digital Encoding System) was presented at the 
ACM national meetings in 1955 [when no proceedings were published] and 
1956 [BL 56"], and at the OMR symposium in 1956 [BL 56']. 

The ADES language is essentially mathematical in structure. It 
is based on the theory of the recursive functions and the schemata 
for such functions, as given by Kleene. [BL 56', p. 72] 

The ADES approach to automatic programming is believed to be 
entirely new. Mathematically, it has its foundations in the 
bedrock of the theory of recursive functions. The proposal 
to apply this theory to automatic programming was first made 
by C. C. Elgot, a former colleague of the author's. While at 
the Naval Ordnance Laboratory, Elgot did some research on a 
language for automatic programming. Some of his ideas were 
adapted to ADES. [BL 56, p. iii] 

A full description of the language was given in a lengthy report 
[BL 56]; it is rather difficult to understand several aspects of ADES, 
and we will content ourselves with a brief glimpse into its structure 
by considering the following ADES program for TPK. (The conventions 
of [BL 57'] are followed here since they are slightly simpler than the 
original proposals in [BL 56].) 
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1 aQlliq^ll, 



2 f^Q = + / abs c^ • • • 5 c^ c^ c^, 

3 d^2^ = ^0' 

h dggbg = < bj J+00, b^, 999, 

6 r^ = -10 q^, 

1 V '^ 1° ^0 = ^0 \ ^2^ 



Here is a roxigh translation: Line 1 is the so-called "computer table", 
meaning that input array aQ has 11 positions, and the "independent 
index symbol" q^ takes 11 values. Line 2 defines the auxiliary fionction 
f^Q , oirr f(t) ; arithmetic expressions were defined in iukasiewicz' s 
parentheses- free notation, now commonly knovm as "left Polish". Variable 
c, here denotes the first parameter of the function, (incidentally, 
"right Polish" notation seems to have been first proposed shortly 
afterwards by C. L. Hamblin in Australia, cf. [HA 573.) 

Line 3 states that the dependent variable b, is equal to the dependent 
index Tq ; the " d-_ " here means that this is to be output as component 1 
of a pair. Line k similarly defines b^ , which is to be component 2 , 
This line is a "branch equation" meaning " if b < 1;00 then b else 999 ". 
(Such branch equations are an embryonic fomi of the conditional expressions 
introduced later by McCarthy into LISP and ALGOL. Blum remarked that the 
equation " < x a, f, g, " could be replaced by cp f + (l-cp)g , where cp 
is a function that takes the value 1 or according as x < a or 
X > a . [BL 56, p. 16] "The function 9 is a primitive rec-uxslve 
function, and could be incorporated into the library as one of the given 
functions of the system. Nevertheless, the branch equation is included 
in the language for practical reasons. Ifeny mathematicians are accustomed 
to that terminology, and it leads to more efficient programs." In spite 
of these statements, Blum may well have intended that f or g not be 
evaluated or even defined when cp = or 1 , respectively. ) 
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Line 5. says that b is the result of applying ft-„ to the r^ -th 
element of a„ . Line 6 explains that r is 10- 0^ • Finally, line 7 
is a so-called "phase equation" which specifies the overall program flow 
by saying that b-, and b are to be evaluated for q^ = 0,1, ...,10 . 

The ADES language is "declarative" in the sense that the programmer 
states relationships between variable quantities without explicitly 
specifying the order of evaluation. John McCarthy put it this way, in 1958: 

Mathematical notation as it presently exists was developed to 
facilitate stating mathematical facts, i.e., making declarative 
sentences. A program gives a machine orders and hence is usually 
constructed out of imperative sentences. This suggests that it 
will be necessary to invent new notations for describing complicated 
procedures, and we will not merely be able to take over intact the 
notations that mathematicians have used for making declarative 
sentences. [EE 58', p. 275] 

The transcript of a I965 discussion of declarative vs. imperative languages, 
with comments by P. Abrahams, P. Z. Ingerman, E. T. Irons, P. Naur, 
B. Raphael, R. V. Smith, C. Strachey, and J. W. Young, appears in 
Comm. ACM 9 (1966), pp. 155-156, 165-166. 

Although ADES was based on recursive function theory, it did not 
really include recursive procedures in the sense of ALGOL 6O; it dealt 
primarily with special types of recursive equations over the integers, 
and the emphasis was on studying the memory requirements for evaluating 
such recurrences. 

An experimental version of ADES was implemented on the IBM 65O, 
and described in [BL 57* BL 57' ]• Blum's translator scheme was what 
we now recognize as a recursive approach to the problem, but the recursion 
was not explicitly stated; he essentially moved things on and off various 
stacks during the course of the algorithm. This implementation points 
up the severe problems people had to face in those days: The ADES 
encoder took 5500 instructions while the Type 65O calculator had room 
for only 2000, so it was necessary to insert the program card decks 
into the machine repeatedly, once for each equationl Because of further 
machine limitations, the above program would have been entered into the 
computer by punching the following information onto six cards: 
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AOO Oil P02 qpo oil POl F50 EGO F02 F20 

F06 COl FOU FOU FOi)- 005 GOl COl COl POl 

D12 BOl EOO ROO POl 1)22 B02 EOO Fll BO3 

ll-OO POl BO5 POl 999 POl BO5 EOO F50 AOO 

ROO POl ROO EOO FO5 010 QpO POl PO3 000 

Qpo 010 BOO EOO FOO BOl B02 POl - 

Thus Pnn was a punctuation mark^ Fnn a function code, etc. Actually 
the implemented version of ADES was a subset that did not allow 
auxiliary f-equations to be defined, so the definition of b., in 
line 5 would have been written out explicitly. 

The^. 

In September, 1955, four members of the Purdue University 
Computing Laboratory — Mark Koschman, Sylvia Orgel, Alan 
Perils, and Joseph W. Smith -- began a series of conferences 
to discuss methods of automatic coding. Joanne Chipps Joined 
the grnuT in Ms.rnh, 195^. _A compiler, programmed to be used 
on the Datatron, was the goal and result. [OR 58, p. 1] 

Purdue received one of the first Datatron computers, manufactured by 
Electrodata Corporation (cf. J. ACM 2 (1955)^ p. 122, and [PE 55]); this machine 
was later known as the Burroughs 205. By the summer of 1956, the Purdue 
group had completed an outline of the basic logic and language of its 
compiler, and they presented some of their ideas at the ACM national 
meeting [CK 56]. It is interesting to note that their 1956 paper 
used both the words "compiler" and "statement" in the modem sense; 
a comparison of the ONR 195^ and 1956 symposium proceedings makes it 
clear that the word "compiler" had by now acquired its new meaning. 
Furthermore the contemporary FORTRAN manuals [IB 56, IB 5?] slso used 
the term "statement" vdiere [IB 5^] had said "formula". Terminology was 
crystallizing. 

At this time Perils and Smith moved to the Carnegie Institute of 
Technology, taking copies of the flowcharts with them, and they adapted 
their language to the IBM 650 (a smaller machine) with the help of 
Harold Van Zoeren. The compiler was put into use in October, 1956, 
(cf. [PS 57^ P» 102]), and it became known as IT, the Internal Translator. 
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Compilation proceeds in two phases: 1) translation from an IT 
program into a symbolic program, PIT and 2) assembly from a PIT 
program into a specific machine coded program, SPIT. [PS 57 S P- 1«23] 

The intermediate "piT" program -was actually a program in SOAP language [PM 55 ]> 
the soiirce code for an excellent symbolic assembly program for the IBM 650. 
Perils has stated that the existence of SOAP was an important simplifying 
factor in their implementation of IT, which was completed about three 
months after its authors had learned the 650 machine language. 

This was the first really useful compiler; IT and IT's derivatives were 
used successfully and frequently in hundreds of computer installations until 
the 650 became obsolete, (indeed, R. B. Wise stated in October, 1958 
that "the IT language is about the closest thing we have today to the universal 
language among computers." [WA 58, p. I5I] ) The previous systems we have 
discussed were important steps along the way, but none of them had the 
combination of powerfiiL language and adequate implementation and documentation 
needed to make a significant Impact in the use of machines. Furthermore, IT 
proved that usefiil compilers could be constructed for small computers 
without enormous investments of manpower. 

Here is an IT program for TPK: 



1 


: READ 


2 


3, 11, 10, -1, 0, 


5 


Yl <- "20E,AC(I1+1)" 




+(5x(C(ll+l)*3)) 


6 


G5 IF J+00.0 > Yl 


7 


Yl - 999 


3 


Til TYl 


10 


H 



Each statement has an identifying number, but the numbers do not have to 
be in order. The READ statement does not specify the names of variables 
being input, since such information appears on the data cards themselves. 
Floating-point variables are called Yl, Y2, ... or CI, C2, . . . ; the above 
program assiimes that the input data will specify eleven values for CI 
thru Cll. 

Statement nxanber 2 designates an iteration of the following program through 
statement number 5 inclusive; variable II runs from 10 in steps of -1 
down to 0. Statement 5 sets Yl to ^(C-r-i^-i) ; the notation " 20E,x " 



8i+ 



is used for "language extension 20 applied to x", where extension 20 
happens to be the floating-point square root subroutine. Note the use 
of mixed integer and floating-point arithmetic here. The redundant 
parentheses emphasize that IT did not deal with operator precedence, 
although in this case the parentheses need not have been written since 
IT evaluated expressions from right to left. 

The letter A is used to denote absolute value, and * means 
exponentiation. Statement 6 goes to 3 if Yl < i|-00 ; and statement 3 
outputs II and Yl . Statement 10 means "halt". 

Since the IBM 650 did not have such a rich character set at the 
time, the above program would actually be punched onto cards in the 
following form -- using K for comma, M for minus, Q for quote, 
L and R for parentheses, etc.: 

0001 READ F 

0002 3K UK lOK MIK OK F 
0005 Yl Z Q 20EK ACLIISIR Q F 

0005 S L5 X LCLllBlR P JRR j' 

0006 G3 IF i^OOJO W Yl F 
0006 Yl Z 999 F 

0003 Til TYl F 
0010 H FF 

The programmer also supplied a "header card", stating the limits on 
array subscripts actually used; in this case the header card would 
say 1 I variable, 1 Y variable, 11 C variables, 10 statements, 
(it was possible to "go to" statement number n, where n was the value 
of any integer expression, so an array of statement locations was kept 
in the riinning program.) 

The Purdue compiler language discussed in [CK 56] was in some respects 
richer than this, it included the ability to type out alphabetic information 
and to define new extensions (functions) in source language. On the other 
hand, [CK 56] did not mention iteration statements or data input. Joanne 
Chipps and Sylvia Orgel completed the Datatron implementation in the 
summer of 1957; the language had lost the richer features in [CK 56], however. 
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probably since they were unexpectedly difficult to implement. Our 
program in the Purdue Compiler language [OR 58] would look like this; 



input 


iO yO clO slO 


f 




[maximum subscripts used] 


1 e 


"800e" f 






[read input] 


2 s 


iO = 10 f 






[set i^ = 10] 


5 s 


yO = "200e, aciO' 


'+(5x 


;(ciOp3)) f 




6 r 


g8, r yO < i;00.0 


f 




[go to 8 if y^ < toO.O] 


7 s 


yO - 999 f 








8 o 


iO f 






[output i ] 


9 o 


yO f 






[output y^] 


h s 


iO = iO-1 f 








3 r 


g5, r < iO f 






[go to 5 if 1q > 0] 


10 h 


f 






[halt] 



Note that subscripts now may start with , and that each statement 
begins with a letter identifying its type. There are enough differences 
between this language and IT to make mechanical translation nontrivial. 

FORTRAN Arrives. 

During all this time the ongoing work on FORTRAN was widely publicized. 
Max Goldstein may have simimed up the feelings of many people when he made 
the following remark in June, 1956: "As far as automatic programming 
goes, we have given it some thought and in the scientific spirit we 
intend to try out FORTRAN when it is available. However ..." [GO 56, p. Uo] 

ml J -_ ! r\^j T n r\ir ^ jj j j-i II .c*^ I. 11 ^ — 

xiic u.ct^ was uuiiLLiig,. uu uuuei.-, j.^^u, WJ. L/iieaaeu. tuiuwiex- xj-i-tju xii 

the history of programming languages, namely a language description T^ich 
was carefiilly written and beautifully typeset, neatly botind with a glossy 
cover. It began thus: 

This manual supersedes all earlier information about the F ortran 
system. It describes the system which will be made available during 
late 1956, and is intended to permit planning and F ortran coding in 
advance of that time. [IB 56, p. 1] 

Object programs produced by Fortran will be nearly as efficient 
as those vnritten by good programmers, [p. 2] 
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"Late 1956" was, of coiirse, a euphemism for April, 1957. Here is how 
Saiil Rosen described FORTRAN'S debut: 

Like most of the early hardware and software systems, Fortran 
was late in delivery, and didn't really work when it was 
delivered. At first people thought it woiild never be done. 
Then Tiiien it was in field test, with many bugs, and with some 
of the most important parts unfinished, many thought it woiald 
never work. It gradually got to the point irtiere a program 
in Fortran had a reasonable expectancy of compiling all the 
way through and maybe even of running. [RO 6h] 

In spite of these difficulties, it is clear that FORTRAN I was 
worth waiting for; it soon was accepted even more enthusiastically 
than its proponents had dreamed. 

A survey in April of this year [1958] of twenty-six 70i| installations 
indicates that over half of them use FORTRAN for more than half 
of their problems. Many use it for 8o^ or more of their work 
(particularly the newer installations) and aJiaost all use it 
for some of their work. The latest records of the 704 users' 
organization, SHARE, show that there are some sixty installations 
equipped to use FORTRAN (representing 66 machines) and recent 
reports of usage indicate that more than half the machine 
instructions for these machines are being produced by FORTRAN. 
[BA 58, p. 2U6] 

On the other hand, not everyone had been converted. The second 
edition of programming ' s first textbook, by Wilkes, Wheeler, and Gill, 
was published in 1957, and the authors concluded their newly- added 
chapter on "automatic programming" with the following cautionary 
remarks : 
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The machine might accept formulas written in ordinary 

mathematical notation, and punched on a specially designed 

keyboard perforator. This would appear at first sight to 

he a veiy significant development, promising to reduce 

greatly the labor of programming. A number of schemes of 

formula recognition have been described or proposed, but 

on examination they are found to be of more limited utility 

than might have been hoped, . . , The best that one could 

expect a general purpose formula-recognition routine to do, 

would be to accept a statement of the problem after it had 

been examined, and if necessary transformed, by a numerical 

analyst . ... Even in more favorable cases, experienced 

programmers will be able to obtain greater efficiency by 

using more conventional methods of programming. [WW 57^ pp. I36-I37] 

An excellent paper by the authors of FORTRAN I, describing both the language 
and the organization of the compiler, was presented at the Western Joint Computer 
Conference in 1957 [BB 57 ]• The new techniques for global program flow analysis 
and optimization, due to Robert A. Nelson, Irving Ziller, Lois M. Haibt, and 
Sheldon Best, were particularly important. By expressing TPK in FORTRAN I 
we can. see most of the language changes that had occurred: 

c the tpk algorithm, fortran style 
funf(t) = sqptf(absf(t))+5.o*t*-^3 
dimension a (11) 

1 FORMAT (6F12.i|) 
READ 1, A 
DO 10 J = 1, 11 

I = 11-J 

Y = FUNF(A(I+1)) 

IF (UOO.O-Y)l^,8,8 
k PRINT 5, I 
:? FORMAT (no, lOH TOO LARGE) 

GO TO 10 

8 PRINT 9, I, Y 

9 FORMAT (no, FI2.7) 
10 CONTINUE 

STOP 52525 



The chief innovations are 

(1) Provision for camments: No programming language designer had thought 
to do this before'. (Asseiably languages had comment cards, but 
programs in higher-level languages were generally felt to be self- 
explanatory. ) 

(2) Arithmetic statement functions were introduced. These were not 
mentioned in [IB 56], but they appeared in [BE 5?] and. (in detail) 
in the Programmer's Primer [IB 57^ pp. 25, 5O-3I] . 

(3) Formats are provided for input and output. This feature, due to 
Roy Nutt, was a major innovation in programming languages; it 
probably had a significant effect in making FORTRAN popular since 
input/output conversions were othervd.se very awkward to express 
on the ^Ok. 

(k) Lesser features not present in [IB 5^] are the CONTINUE statement, 
and the ability to display a five-digit octal number -when the 
machine halted at a STOP statement. 

MA/m_MATTC and FLOW-MATtp . 

Meanwhile, Grace Hopper's programming group at UNIVAC had also been busy. 
They had begun to develop an algebraic language in 1955, a project that was 
headed by Charles Katz, and the compiler was released to two installations for 
experimental tests in 1956. (Cf. [BE 57], p. 112.) The language was originally 
called AT-3; but it received the catchier name MATH-MATIC in April, 1957, ishen 
its preliminary manual [AB 57] was released. The following program for TPK 
gives MATH-MATIC s flavor: 

(1) READ- ITEM A(11) . 

(2) VARY I 10(-1)0 SENTENCE 3 THRU 10 . 

(3) J = I+l . 

{h) Y = SQR |a(J)| + 5*A(J)^ . 

(5 ) IF Y > UOO, JUMP TO SENTENCE 8 . 

(6) PRINT-OUT I, Y . 

(7) JUMP TO SENTENCE 10 . 

(8) z = 999 . 

(9) PRINT-OUT I, Z . 

(10) IGNORE . 

(11) STOP . 



The language was quite readable; note the vertical bar and the superscript 
3 in sentence {k), indicating an extended character set that co-uld be 
used with some peripherals. But the MATH-MATIC programmers did not share 
the FORTRAN group's enthusiasm for efficient machine code; they translated 
MATH-MATIC source language into A-3 (an extension of A-2)^ and this 
produced extremely inefficient programs, especially considering the fact 
that arithmetic was aJLl done by floating-point subroutines. The UNTVAC 
computer was no match for an IBM ^Ok even when it was expertly programmed, 
so MATH-MATIC was of limited utility. 

The other product of Grace Hopper's programming staff was far more 
influential and successful, since it broke important new ground. This 
was what she originally called the Data-Processing compiler in January, 
1955; it was soon to be known as "B-0", later as the "Procediu-e 
Translator" [KM 5?]^ and finally as FLOW-MATIC [HO 58, TA 6o] . This 
language used English words, somewhat as MATH-MATIC did but more so, 
and its operations concentrated on business applications. The following 
examples are typical of FLOW-MATIC operations: 

(1) COMPARE PART-NUMBER (a) TO PART-NUMBER (B) ; IF GREATER GO TO 
OPERATION 13 ; IF EQUAL GO TO OPERATION 1^ ; OTHERWISE GO TO 
OPERATION 2 . 

(2) READ- ITEM B ; IF END OF DATA GO TO OPERATION 10 . 

The allowable English templates are shown in [SA 69, pp. 317-322], 

The first experimental B-0 compiler was operating in I956 [HO 58, 

T). 171]. Snrt if. wns TPI Pasf^ri +.0 TTM'nT'Ar' nn^+nrne^fa nn 1 Ql^ft T q A (^n -r, -^1(^1 

FLOW-MATIC had a significant effect on the design of COBOL in 1959. 

A Formula-controlled Computer. 

At the internationaJ. computing colloquium in Dresden, 1955^ Klaus Samelson 
presented the rudiments of a particularly elegant approach to algebraic 
fomiula recognition [SA 55]^ improving on Bohm' s technique, Samelson and 
his colleague F, L, Bauer developed this method during the ensuing years, 
and their subsequent paper [SB 59] describing it became well known. 
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One of the first things they did with their approach was to design 
a computer in which algebraic formulas themselves were the machine 
language. This computer design was submitted to the German patent office 
in the spring of I957 [BS 5?]^ and to the U.S. patent office (with the 
addition of wiring diagrams) a year later. Although the German patent was 
never granted, and the machines were never actually constructed, Bauer and 
Samelson eventually received U.S. Patent 5,0^^7,228 for this work [BS 6?]. 

Their patent describes four possible levels of language and machine. At 
the lowest level they introduced something like the language used on today's pocket 
calculators, allowing formulas consisting only of operators, parentheses, 
and numbers, while their highest level includes provision for a full- 
fledged programming language incorporating such features as variables 
with multiple subscripts and decimal arithmetic with arbitrary precision. 

The language of Bauer and Samelson' s highest-level machine is of 
principal concern to us here. A program for TPK could be entered on 
its keyboard by typing the following: 



1 0> 0000.00000000 => alllt 



2 


2.27 ==> ailt 


5 


3.528 =* a;2T 


12 


• • • 

5.2876i^ => ailir 


13 


10 ^ i 


11^ 


hk* aii+lt => t 


15 


/ Bt+5xtxtxt -* y 


16 


i =□ J ^ i 


17 


y > 1^00 - 77* 


18 


y =aau .aau => y 


19 


- 88* 


20 


77* 999 =□□□ .□□ J =^ y 


21 


88* i-l =* i 


22 


i > -1 _ ij-i^.* 



(This is the American version; the German version would be the same if 
all the decimal points were replaced by commas.) 
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The " ^ " at the beginning of this program is optional; it means that 
the ensuing statements up to the next label ( hk^ ) will not enter the 
machine's "formula storage", they will simply be performed and forgotten. 
The remainder of line 1 specifies storage allocation; it says that a is 
an 11-element array whose entries will contain at most 12 digits. 

Lines 2 through 12 enter the data into array a . The machine also 
included a paper tape reader in addition to its keyboard input; and if the 
data were to be entered from paper tape, lines 2 through 12 could be 
replaced by the code 

1 => i 
33* •••••• ^ alit 

i+1 => i 

i < 12 - 35* 

Actually this input convention was not specifically mentioned in the patent, 
but Bauer [BA 76'] recalls that such a format was intended. 

The symbols i and t for subscripts would be entered on the keyboard 
but they would not actually appear on the printed page; instead, the 
printing mechanism was intended to shift up and down. The equal signs 
followed by square boxes on lines I6, I8, and 20 indicate output of a 
specified number of digits, showing the desired decimal point location. 
The rest of the above program should be self-explanatory, except perhaps 
for the B in line 15_ which denotes absolute value ("Betrag"), 



Summary . 

We have now reached the end of our story, having covered essentially 
every high-level language whose design began before 1957* I't is 
impossible to summarize all of the languages we have discussed by 
preparing a neat little chart; but everybody likes to see a neat little 
chart, so here is an attempt at a rough but perhaps meaningful comparison. 
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Language 



Flow DiaercOES 

Composition 
Siiort Code 
Intenaedlate PL 
Klammerausdrucke 

FoiTiuleE 

Aut, code 

A-2 

Algebraic interrri 

Autocode 

mT-2 . 
mr 

BACAIC 

KOMFILEE 2 

ADES 

IT 

FORTRAH I 

I.1ATH-:'ATIC 

Patent 5,01+7,228 



Principal 
Author(E) 



Goldsuine/ 
von Neumann 

Curry 

Mauchly 

Burks 

Kutisha>'Ger 

Eo!-jn 



Year 



Laninc/ 
:;ierler 


li33 


Brooker 


195 H 


tiair.j^ij.n/ 
Lfubircski? 


xv> -t 


Ershov 


19?5 


Grerns/ Porter 


1955 


Elsworth/Kulin 


1955 


Bl\m 


1956 


Perils 


1956 


BackuE 


ly5'^ 


Katz 


195 6 


Bauer/ 
GamelLon 


1957 



I9lj6 

191+8 
1950 
1950 
1951 
1951 

195t 



X, f,, F 

X 



*-) i' 



C |C 

I 

I) : c 

lL 



First 



B C 



I'rograjiiirdng language, ,1^ orarcniO 
Accepted prograj-jnlnc ae'.hodclugy 

Code gen'iration ulgoritlrJTi 

High level language ii,.^leir.enLed 



uomirion -iuu 






ticn, i3c 



t;ir':plfc code g^; 

Compiler in own Ic-ngii-.tre 

i;;-efui co:nxili;r 

Macro oxpanut=r 

Ccn -taii^s in -rcnmilaf 



Book about a oon.piler 

Expression-oriented 

Scaling aids 

Declarative language 

Guccessiul ccEpiler, change of -achine 

I/O fomats, global ci.t Iv.Lzation 

Heavy uce of li^glisli 

i'orLTola-contr oiled coiaputer 



Table 1 
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Table 1 shows the principal mathematically-oriented languages we 
have discussed, together with their chief authors and approximate year 
of greatest research or development activity. The "arithmetic" column 
shows X for languages that deal with integers, F for languages that 
deal with floating-point numbers, and S for languages that deal with 
scaled numbers. The remaining columns of Table 1 are filled with very 
subjective "ratings" of the languages and associated programming systems 
according to various criteria. 

Implementation: Was the language implemented on a real computer? 
If so, how efficient and/or easy to use was it? 

Readability: How easy is it to read programs in the language? 

(This includes such things as the variety of symbols usable 
for variables, the closeness to familiar notations.) 

Control structures: How high-level are the control structures? 
Are the existing control structures sufficiently powerful? 
(By "high level" we mean a level of abstraction; something 
the language has that the machine does not . ) 

Data structuj:'es: How high-level are the data strictures? (For 
example, can variables be subscripted?) 

Machine independence: How much does a programmer need to keep 
in mind about the underlying machine? 

Impact : How many people are known to have been directly influenced 
by this work at the time? 

Finally there is a column of "firsts", which states some new thing(s) 
this particular language or system introduced. 

The Sequel. 

What have we not seen, among all these languages? The most significant 
gaps are the lack of high-level data structures other than arrays (except 
in Zuse's impublished language); the lack of high level control structures 
other than iteration controlled by an index variable; and the lack of 
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recursion. These three concepts, which now are considered absolutely 
fundamental in computer science, did not find their way into languages 
until the 1960's, Our languages today probably have too many features, 
but the languages up to FORTEM I had too few. 

At the time our story leaves off, explosive growth in language 
development was about to take place, since the successful compilers 
touched off a language bocan. Programming languages had reached a stage 
when people began to write translators from IT to FORTRAN [GR 58] and 
from FORTRAN to IT (cf. [BO 58], who describes the FOR TRANSIT compiler 
which was developed by a group of programmers at IBM under the direction 
of R. W. Bemer and D. Hemmes). An excellent survey of the state of 
automatic programming at the time was prepared by R. W. Bemer [BE 57]« 

Perhaps the most significant development then in the wind was the 
international project attempting to define a "standard" algorithmic 
language. Just after the 1955 meeting in Darmstadt, a group of 
European computer scientists began to plan a new language (cf. [LE 55])^ 
under the auspices of the Gesellschaft fur Angewandte Mathematik und 
iviecnaiiiii ^uiiiwi, cne AiSSQCj.abj.oii j.ul Appj-j-Su. iviaoiiCiiictoj-Ckj 0.11^. i.-i6ciicUij-ijKjy . 
They later invited American participation, and an ad hoc ACM committee 
chaired by Alan Perlis met several times beginning in Januarj'-, I958. 
During the summer of that year, Zurich was the site of a meeting attended 
by representatives of the American and European committees: J. W. Backus, 
F. L. Bauer, H, Bottenbruch, C. Katz, A. J. Perlis, H. Rutishauser, 
K. Samelson, and J. H. Wegstein. (See [BB 58] for the language proposed 
by the European delegates.) 

It seems fitting to bring oxir story to a close by stating the TPK 
algorithm in the "International Algebraic Language" (lAL, later called 
ALGOL) developed at that historic Zurich meeting [PS 58] : 
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procedure TPK (a[]) =; b[]; 

arra^ (a[0:10],b[0:21] ); 

cranment given 11 input values a[0], . . .,a[10], this procedure 

produces 22 output values b[0], . . .,b[21], according 

to the classical TPK algorithm; 
begd£ for i := 10(-1)0; 
'begija y := f(a[i]); 

f(t) := sqrt(abs(t))+5 xtt5M 
if (y > J+00); y := 999; 
b[20-2xi] := i; 
b[21-2xi] := y 
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